March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

by stepharo

Sean Could you stop crying because this is a bit boring? Can we do mistake? Yes How much time the change I did stayed? 20 hours? About 15086 was it not a consequence of some of your changes? Why did you review it? I think that you do not realize the difficulty to assess and integrate code that you do not develop. So instead of crying help. Stef Le 22/3/15 23:41, Sean P. DeNigris a Ã©crit : > I am clear on Pharo's vision, so I'm happy to adapt to our dizzying pace of > change that comes with progress toward it. > > But... there is one area where I feel we need a bit more consensus before > blazing a trail... changes to the UI workflow of existing IDE tools. I'm not > talking about GT, which aims to reinvent the IDE. I'm talking about subtle > changes in the effect of certain button clicks or shortcuts which can lead > to gnashing of teeth as unsuspecting users: > 1. get a funny feeling that something is wrong, but can't quite put their > finger on it > 2. blame themselves that they must have been doing something different all > along > 3. start the bug report process only to eventually find out that this is a > "feature" > etc... > > These specifically threw me for a loop: > 14890 Browsing a different class should select by default the previously > browsed method > which made it seem impossible to get back to a class template in Nautilus > 14666 When doing a "implementors of" with a selector that has 1 implementor > --> neverthless open method list > which requires extra clicks to get back to the full power of a class > browser for no apparent (to me at the time) gain > 15086 Ctrl + Arrow Behaviour > which disabled horizontal mouse scrolling, which I've come to depend on in > my projects > > And so I have a Policy Suggestion: IDE UI workflow changes /must/ be > discussed on the list prior to > integration. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

March 23, 2015

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

by Marcus Denker

> On 22 Mar 2015, at 23:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > 15086 Ctrl + Arrow Behaviour > which disabled horizontal mouse scrolling, which I've come to depend on in > my projects > Was this not a side effect of a change *you* did? Marcus

March 23, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Marcus Denker

> On 22 Mar 2015, at 22:56, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Damien, > > I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip) > I do not think that this is a good idea: we are not building a Museum. For example, we improve the core libraries. It will make something like Metacello *very* complex to be compatible over so many versions back. In the end, people who have this philosophy start to even request âto make this easierâ, and then tell us to stop changing. Make your live easier and do *not* support old versions! Everything gets easier and the world will be a happier place. Marcus

March 23, 2015

Re: [Pharo-dev] UI Workflows Are Like Snowflakes

by Alain Rastoul

Le 22/03/2015 23:41, Sean P. DeNigris a Ã©crit : > 15086 Ctrl + Arrow Behaviour > which disabled horizontal mouse scrolling, which I've come to depend on in > my projects > > And so I have a Policy Suggestion: IDE UI workflow changes /must/ be > discussed on the list prior to > integration. > Hi Sean, Agree, but in case of mousewheel integration, I suspect it was more a bug or side effect not discovered in time. The use of Ctrl-Arrow is a standard feature on Unix and Windows (I don't know for Mac), and should not be changed. Using Alt-arrow is just impossible, I tried for few time but went crazy, it was a real pain for me, nearly unusable. I guess the same for lot of users who do not have an horizontal mouse wheel and/or a Mac (?). The problem is at the vm level, mouse wheel events must be mapped differently, it's impossible to use the same keyboard combination for two different usages. I tried yesterday to build the vm on linux but got problems with some libraries. I'll try again this week, may be the solution is not that hard, simply add an extra indicator 'Alt' +Ctrl+Arrow ?. -- Regards, Alain

March 22, 2015

UI Workflows Are Like Snowflakes

by Sean P. DeNigris

I am clear on Pharo's vision, so I'm happy to adapt to our dizzying pace of change that comes with progress toward it. But... there is one area where I feel we need a bit more consensus before blazing a trail... changes to the UI workflow of existing IDE tools. I'm not talking about GT, which aims to reinvent the IDE. I'm talking about subtle changes in the effect of certain button clicks or shortcuts which can lead to gnashing of teeth as unsuspecting users: 1. get a funny feeling that something is wrong, but can't quite put their finger on it 2. blame themselves that they must have been doing something different all along 3. start the bug report process only to eventually find out that this is a "feature" etc... These specifically threw me for a loop: 14890 Browsing a different class should select by default the previously browsed method which made it seem impossible to get back to a class template in Nautilus 14666 When doing a "implementors of" with a selector that has 1 implementor --> neverthless open method list which requires extra clicks to get back to the full power of a class browser for no apparent (to me at the time) gain 15086 Ctrl + Arrow Behaviour which disabled horizontal mouse scrolling, which I've come to depend on in my projects And so I have a Policy Suggestion: IDE UI workflow changes /must/ be discussed on the list prior to integration. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 22, 2015

Re: [Pharo-dev] QUESTION: Is anybody using zeroconf with Pharo 2.0?

by Dale Henrichs

Damien, I'm using zeroconf for Pharo 1.2, 1.4 and 2.0 ... I still test Metacello against Pharo1.1 ... I would use zeroconf with 1.3 but there is something funkily different between what is available on zeroconf for 1.3 and what actually "works" for for 1.3 (https://gforge.inria.fr/frs/download.php/30567/PharoCore-1.3-13328.zip) Dale On 3/13/15 5:04 AM, Damien Cassou wrote: > Esteban Lorenzano writes: > >> thatâ¦ is someone using it? > I think the pharo-users mailing list is more appropriate >

March 22, 2015

Re: [Pharo-dev] Color arithmetical operations are broken

by Nicolai Hess

2015-03-22 21:26 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > > On Sun, Mar 22, 2015 at 8:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Yes, but I think the operation were defined as the Color class did not >> contain the alpha value > > > Exactly > > Ah, Ok. In that case I would not use the arithmetic operations at all. >> never :) > > > I wanted to solve the problem without actually solving it :) > > In the image there is a general animation class that supports linear > interpolation defined as: > >> (to - from) * delta + from > > So it can theoretically work with all objects polymorphic with numbers in > sense of math operations. I browsed Color class and surprisingly found that > it is polymorphic with Number! What a lucky moment :) However when I tried > I failed. Then I realized that color's value can't be negative, so > general solution will not work, since (to - from) can't be negative > Color. > In that case you may be interested on this issue: 15138 <https://pharo.fogbugz.com/default.asp?15138> inprecise interpolateTo:at: for floats > > That is why I had to interpolate each channel separately: > > |r g b a| >> r := (to red - from red) * delta + from red. >> g := (to green - from green) * delta + from green. >> b := (to blue - from blue) * delta + from blue. >> a := (to alpha - from alpha) * delta + from alpha. >> ^ Color r: r g: g b: b alpha: a > > > I don't need math operations with colors anymore :) But having that > feature doesn't work we should do something before release ;) That's why > issue was opened. Feel free to make slice requests > > Cheers, > Alex >

March 22, 2015

Re: [Pharo-dev] Color arithmetical operations are broken

by Aliaksei Syrel

On Sun, Mar 22, 2015 at 8:17 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Yes, but I think the operation were defined as the Color class did not > contain the alpha value Exactly Ah, Ok. In that case I would not use the arithmetic operations at all. > never :) I wanted to solve the problem without actually solving it :) In the image there is a general animation class that supports linear interpolation defined as: > (to - from) * delta + from So it can theoretically work with all objects polymorphic with numbers in sense of math operations. I browsed Color class and surprisingly found that it is polymorphic with Number! What a lucky moment :) However when I tried I failed. Then I realized that color's value can't be negative, so general solution will not work, since (to - from) can't be negative Color. That is why I had to interpolate each channel separately: |r g b a| > r := (to red - from red) * delta + from red. > g := (to green - from green) * delta + from green. > b := (to blue - from blue) * delta + from blue. > a := (to alpha - from alpha) * delta + from alpha. > ^ Color r: r g: g b: b alpha: a I don't need math operations with colors anymore :) But having that feature doesn't work we should do something before release ;) That's why issue was opened. Feel free to make slice requests Cheers, Alex

March 22, 2015

Re: [Pharo-dev] Jenkins - the reason of error

by Nicolai Hess

2015-03-21 23:14 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > is it possible to find in CI why a particular test has failed? > > For example here > https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/27669//artifact/val… > > it only shows the name of the method, but not the assert itself, nor some > kind of debug log. Is this info available elsewhere? > I don't think so. I could not find a way. > > Thanks, > Peter >

March 22, 2015

Re: [Pharo-dev] Color arithmetical operations are broken

by Nicolai Hess

2015-03-22 15:06 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Color white - (Color white alpha:0) = Color white >> Color white - (Color white alpha:0.5) = Color gray. >> Color white - (Color white alpha:1.0) = Color black. >> For what do you need the color arithmetic ? >> Maybe there are already other operations defined on Color that you can >> used instead. > > > That is too complicated :) > The idea was to have one-line fix that just leaves the behaviour as it was > before, simply makes it not produce garbage. > Yes, but I think the operation were defined as the Color class did not contain the alpha value > Basically there should be a long discussion after pharo 4 is released. > > How it is now: > (Color white alpha: 0) = Color transparent => false > Color white - (Color white alpha: 0) = Color black => true > > From logical point of view is should not be black. But from mathematical > point of view Color is just a vector and operations with it should be the > same or almost the same as with vectors. > Yes and no, I don't think the mathematical point of view should play here. Color is not just a vector. > > For what do you need the color arithmetic ? > > I wanted to get linear discrete transformation from one color to another > to use it in animation > Ah, Ok. In that case I would not use the arithmetic operations at all. never :) What is wrong with Color>>mix:shades: ? | w r cl | cl := Color red mix: Color green shades:50. w := Display width // cl size. r := 0@0 extent: w@((w min: 30) max: 10). cl do: [:c | Display fill: r fillColor: c. r := r translateBy: w@0]. Or do you need to change the alpha based on the operands? Nicolai > > Cheers, > Alex > > On Sun, Mar 22, 2015 at 1:54 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> On 22 Mar 2015, at 13:35, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> >> >> 2015-03-22 12:43 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> >>> >>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> Why not take the average of alpha in all cases? >>>> >>>> Eliot (phone) >>>> >>>> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >>>> wrote: >>>> >>> >>> >>> Or weight the argument by its alpha and don't change the alpha of the >>> receiver: >>> Color white - (Color white alpha:0) = Color white >>> Color white - (Color white alpha:0.5) = Color gray. >>> Color white - (Color white alpha:1.0) = Color black. >>> >>> For what do you need the color arithmetic ? >>> Maybe there are already other operations defined on Color that you can >>> used instead. >>> >>> As the arithmetic operations on Color doesn't work (for years?), maybe >>> we should remove >>> the operation now, and replace them with a more verbose api >>> addRGB/ addRGBA/ subRGBA .... >>> >>> nicolai >>> >>> >> Ah, this issue is already closed. That was a rather short discussion. And >> #/ and #* still don't work >> for colors. >> >> >> Yesâ¦ I think we have a problem that there is no âthis is ready for >> integrationâ check. >> >> We need to get more carefulâ¦ >> >> Marcus >> > >

March 22, 2015