Re: [Pharo-dev] [Pharo-users] Cleaning/Simplifying Nautilus

[Marcus Denker]

> On 22 Mar 2015, at 00:31, Sven Van Caekenberghe  wrote:
> 
> But seriously, for 4.0 ?
> Now ?
> 

No, for Pharo5 of course. If you check the issue, it has explicit the Milestone 
“Later”.

For Pharo4, we need to be careful: there are still 57 open issues, and it will 
be a challenge
to fix them in one week…

Marcus

[Pharo-dev] [Pharo4] 8 issues need a review

[Marcus Denker]

Hi,

People are busy fixing very nice! We have now 8 that need a human review:

https://pharo.fogbugz.com/f/filters/45/Review 


Marcus

Re: [Pharo-dev] ClassCommented announcement missing

[Marcus Denker]

I know why!

The old class builder did not have an API to set the comment when building or 
changing a class.
So Monticello actually created the class and *then* it explicitly set a comment.

When I did the change to support Slot definitions, I moved MC over to the new 
API and set the comment
directly when creating the class. (Interesting how simple the code got…).

So this means that in the past MC never used the class builder to set the 
comment… or maybe in some cases,
the comment change was even announced double?

I think we an just remove the #suspendAllWhile: guard.

> On 21 Mar 2015, at 15:01, Nicolai Hess  wrote:
> 
> Someone knows why ClassCommented-announcements aren't 
> announced during a mc package load ?
> 
> see: 
> 15190 
> Nautilus incorrectly flags Error classes as "missing class comments"
> 
> and
> SlotClassBuilder>>#build
> 
> 
> SystemAnnouncer uniqueInstance suspendAllWhile: [
> comment ifNotNil: [result classComment: comment stamp: 
> commentStamp]].

[Pharo-dev] [pharo-project/pharo-core] c936b0: 40573

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c936b071a0a8407db549c3ef356d58893912678a
  
https://github.com/pharo-project/pharo-core/commit/c936b071a0a8407db549c3ef356d58893912678a
  Author: Jenkins Build Server 
  Date:   2015-03-22 (Sun, 22 Mar 2015)

  Changed paths:
M Graphics-Primitives.package/Color.class/instance/transformations/%2A.st
M Graphics-Primitives.package/Color.class/instance/transformations/%2F.st
M Graphics-Primitives.package/Color.class/instance/transformations/+.st
M Graphics-Primitives.package/Color.class/instance/transformations/-.st
A Morphic-Widgets-Pluggable.package/PluggableTextMorph.class/instance/menu 
commands/basicInspectIt.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script572.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script573.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40572.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40573.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A 
Slot-Tests.package/SlotExampleTest.class/instance/tests/testExampleClassSide.st
A 
Slot-Tests.package/SlotExampleTest.class/instance/tests/testExampleTwoSlotWithState.st
M Spec-Core.package/TabManagerModel.class/instance/api/addTab_.st
M Spec-Inspector.package/EyeInspector.class/class/tools 
registry/registerToolsOn_.st
A Spec-Inspector.package/extension/Object/instance/basicInspect.st
M Spec-Tests.package/TabModelTest.class/instance/tests/testChangeLabel.st
A 
Spec-Tests.package/TabModelTest.class/instance/tests/testInitialSelectedTab.st
M Text-Edition.package/SmalltalkEditor.class/class/menu 
declaration/smalltalkEditorMenuOn_.st
M Text-Edition.package/SmalltalkEditor.class/instance/do-its/exploreIt.st

  Log Message:
  ---
  40573
15145 Spec TabManager selectedTab returns nil after first opening
https://pharo.fogbugz.com/f/cases/15145

15182 add basic inspector option
https://pharo.fogbugz.com/f/cases/15182

15195 test for redefined Slots on class side
https://pharo.fogbugz.com/f/cases/15195

15188 Color ariphmetical operations are broken
https://pharo.fogbugz.com/f/cases/15188

http://files.pharo.org/image/40/40573.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40573
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] "Suggestions" menu entry not in GTPlayground > Any reason why?

[p...@highoctane.be]

Or how to get them back?

TIA
Phil

[Pharo-dev] about Groups in Nautilus

[stepharo]

Hi

I'm analysing the behavior of groups in nautilus.

- Add group works well.
   This is really cool to be able to promote a package in the top focus 
list.
The problem is that the group is not polymorph to a package so we 
cannot publish but for now this should be ok.


-2 Now
Add as Groups & Browse
does not work for me since it open a browser that only contains the 
groups but the refresh ... does not work.
Then this is strange because after we can still find a class that 
is not in the original package.


- 3 Now
Add Matching ... could work if ask for a pattern and stop to browse 
(cf above).


- 4 Add in group does not propose the currently available groups (only Work)

- merge groups
-> raises a DNU


So I will remove 2 and implement 3

https://pharo.fogbugz.com/default.asp?15202

Stef

Re: [Pharo-dev] "Suggestions" menu entry not in GTPlayground > Any reason why?

[Tudor Girba]

Because I haven't seen a suggestion for the Workspace. Could you give me
concrete examples of suggestions that work in the Workspace?

Doru

On Sun, Mar 22, 2015 at 10:14 AM, p...@highoctane.be 
wrote:

> Or how to get them back?
>
> TIA
> Phil
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

[Pharo-dev] [pharo-project/pharo-core] 9129ad: 40574

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 9129ade62bd9405aca9894fb1abe1df9b4acd3d9
  
https://github.com/pharo-project/pharo-core/commit/9129ade62bd9405aca9894fb1abe1df9b4acd3d9
  Author: Jenkins Build Server 
  Date:   2015-03-22 (Sun, 22 Mar 2015)

  Changed paths:
M Morphic-Core.package/HandMorph.class/instance/private 
events/generateKeyboardEvent_.st
M Nautilus.package/MethodWidget.class/instance/protocol/updateMethodList_.st
M 
Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st
M 
OpalCompiler-Core.package/OCASTTranslator.class/instance/visitor/visitNode_.st
M Reflectivity-Tests.package/ReflectiveMethodTest.class/definition.st
A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/as yet 
unclassified/tagExec.st
M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - 
links/testUninstallLinkAndRun.st
A Reflectivity.package/MetaLink.class/class/as yet 
unclassified/uninstallAll.st
M Reflectivity.package/MetaLink.class/instance/ast/hook.st
A Reflectivity.package/extension/RBProgramNode/instance/afterLinks.st
A Reflectivity.package/extension/RBProgramNode/instance/beforeLinks.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script573.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script574.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40573.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40574.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A 
Spec-Core.package/TextInputFieldModel.class/instance/api/enableGlobalsCompletion.st
M 
Spec-Core.package/TextInputFieldModel.class/instance/initialization/initialize.st
R 
Spec-Core.package/TextInputFieldModel.class/instance/private/defaultEntryCompletion.st
A 
Spec-Core.package/TextInputFieldModel.class/instance/private/globalsEntryCompletion.st

  Log Message:
  ---
  40574
15192 revert 14890
https://pharo.fogbugz.com/f/cases/15192

15151 TextInputFieldModel creation is slow
https://pharo.fogbugz.com/f/cases/15151

15196 Simple before and after links with minimal disturbance
https://pharo.fogbugz.com/f/cases/15196

15086 Ctrl + Arrow Behaviour
https://pharo.fogbugz.com/f/cases/15086

http://files.pharo.org/image/40/40574.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40574
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

[Ben Coman]

That is very cool. But I need to ask the tough question - given that the
feature freeze was three weeks ago, what do we gain by adding this in Pharo
4?

* Is it needed for demonstrations that won't be based off latest features
in Pharo 5 ?

* Are third party libraries expected to be based only off Pharo 4 MetaLink
features, rather than additional MetaLink features it sounds like Pharo 5
will get ?

> which means this slice should not impact anything

Because "should" being the operative word... is a slippery slope. If we
have a philosophy of freezing features before a Release, then we should
have the discipline to hold to that - at least in last 7 days before
Release.

cheers -ben


On Sat, Mar 21, 2015 at 11:56 PM, Marcus Denker 
wrote:

> Hi,
>
> After loading this:
>
>
> https://pharo.fogbugz.com/f/cases/15196/Simple-before-and-after-links-with-minimal-disturbance
>
> Simple after and before MetaLinks are taken into account, with just one
> check in #visitNode of the ASTTranslator that is
> false when no links are there. (which means this slice should not impact
> anything)
>
> For now this is for very simple MetaLinks: no parameters, no condition, no
> reification, no #instead/around,
> no meta-level modelling.
>
> Here is a trivial example:
>
> 1) get a AST node from our example method:
>
> sendNode := (ReflectivityExamples>>#exampleMethod) ast body statements
> first value.
>
> 2) then we define a link that is just #halt:
>
> link := MetaLink new
> metaObject: Halt;
>  selector: #now.
>
> 3) we set it:
>
> sendNode link: link.
>
> 4) when we now execute the method, we get a halt:
>
> ReflectivityExamples new exampleMethod
>
> 5) to get rid of it, uninstall the link:
>
> link uninstall.
>
> If you look at the byte code, you see that it compiles the link to the
> code:
>
> 25 <20> pushConstant: Halt
> 26  send: now
>
> Marcus
>
>

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

[Marcus Denker]

> On 22 Mar 2015, at 11:33, Ben Coman  wrote:
> 
> That is very cool. But I need to ask the tough question - given that the 
> feature freeze was three weeks ago, what do we gain by adding this in Pharo 
> 4?  
> 
> * Is it needed for demonstrations that won't be based off latest features in 
> Pharo 5 ?
> 
> * Are third party libraries expected to be based only off Pharo 4 MetaLink 
> features, rather than additional MetaLink features it sounds like Pharo 5 
> will get ?
> 
> > which means this slice should not impact anything
> 
> Because "should" being the operative word... is a slippery slope. If we have 
> a philosophy of freezing features before a Release, then we should have the 
> discipline to hold to that - at least in last 7 days before Release.
> 

Yes, maybe we should postpone it… releasing is boring, I have to admit :-)

Marcus

Re: [Pharo-dev] PharoLauncher: Great Tool, Confusing Name

[Sean P. DeNigris]

> I agree, I like PharoLauncher. It works very well. Sean, you didn't add 
> a "deploy this image on Digital Ocean" command yet? 
I know, I’m such a slacker ;) Shouldn’t be too hard, though…



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/PharoLauncher-Great-Tool-Confusing-Name-tp4813698p4814033.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[Nicolai Hess]

2015-03-21 15:51 GMT+01:00 Eliot Miranda :

> Why not take the average of alpha in all cases?
>
> Eliot (phone)
>
> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel  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






>
>
> On Sat, Mar 21, 2015 at 3:41 AM, Ben Coman  wrote:
>
>> Do we need to do something for Pharo 4? And what is the simplest/quickest
>> thing that would work - even if it needs revisiting in Pharo 5?
>
>
> The most simple that works is to at least set alpha to any value.
>
>- Multiplication - alpha doesn't change
>- Division - alpha doesn't change
>- Addition - (color1 apha + color2 alpha) min: 1.0 - simple addition
>and check to not allow alpha to overcome max value
>- Subtraction - if two colors are the same alpha becomes 0, otherwise
>we take alpha of message receiver (minuend)
>
> Slice is in inbox (15188)
>
> Cheers,
> Alex
>
>

Re: [Pharo-dev] TextMorph scrolling the text on edit or selection operations

[Ben Coman]

Can't say that I noticed it.  There is no information on that issue on how
to reproduce it. Sounds like you've got two use cases.  Can you provide
some specific examples of these so I can observe the behaviour.
cheers -ben

On Sun, Mar 22, 2015 at 3:19 AM, Johan Fabry  wrote:

> Hi all,
>
> I am assuming that I am not the only one that gets very annoyed when a
> TextMorph scrolls the text when typing, such that the line I am typing is
> always at the bottom, or scrolls the debugger when I am stepping over
> instructions. I looked into this (bug
>
> https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-when-accepting-text
> actually) and I found a fix.
>
> But first I want to understand why the code is as it is. Anybody have any
> idea why PluggableTextMorph>>setTextBasic: starts with scrollBar setValue:
> 0.0. ?? If I remove this line the very annoying behavior is gone, and as
> far as I can see there are no negative consequences on text handling (and
> scrolling) in general. So I am wondering why it is there at all.
>
> A slice with my fix is in the inbox if you want to play a bit with it:
> SLICE-Issue-12569-TextModel-should-not-move-scroll-when-accepting-text-johanfabry.1
>
> Please have a look, this behavior has been getting on my nerves for quite
> some time now …
>
>
> ---> Save our in-boxes! http://emailcharter.org <---
>
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
>
>
>

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

[Nicolai Hess]

2015-03-22 12:43 GMT+01:00 Nicolai Hess :

>
>
> 2015-03-21 15:51 GMT+01:00 Eliot Miranda :
>
>> Why not take the average of alpha in all cases?
>>
>> Eliot (phone)
>>
>> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel  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.




>
>
>
>
>
>>
>>
>> On Sat, Mar 21, 2015 at 3:41 AM, Ben Coman  wrote:
>>
>>> Do we need to do something for Pharo 4? And what is the
>>> simplest/quickest thing that would work - even if it needs revisiting in
>>> Pharo 5?
>>
>>
>> The most simple that works is to at least set alpha to any value.
>>
>>- Multiplication - alpha doesn't change
>>- Division - alpha doesn't change
>>- Addition - (color1 apha + color2 alpha) min: 1.0 - simple addition
>>and check to not allow alpha to overcome max value
>>- Subtraction - if two colors are the same alpha becomes 0, otherwise
>>we take alpha of message receiver (minuend)
>>
>> Slice is in inbox (15188)
>>
>> Cheers,
>> Alex
>>
>>
>

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

[Nicolai Hess]

No wait, multiplication and division aren't supposed to work with colors ,
only aNumberOrArray.
And this is working now.

2015-03-22 13:35 GMT+01:00 Nicolai Hess :

>
>
> 2015-03-22 12:43 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda :
>>
>>> Why not take the average of alpha in all cases?
>>>
>>> Eliot (phone)
>>>
>>> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel 
>>> 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.
>
>
>
>
>>
>>
>>
>>
>>
>>>
>>>
>>> On Sat, Mar 21, 2015 at 3:41 AM, Ben Coman  wrote:
>>>
 Do we need to do something for Pharo 4? And what is the
 simplest/quickest thing that would work - even if it needs revisiting in
 Pharo 5?
>>>
>>>
>>> The most simple that works is to at least set alpha to any value.
>>>
>>>- Multiplication - alpha doesn't change
>>>- Division - alpha doesn't change
>>>- Addition - (color1 apha + color2 alpha) min: 1.0 - simple addition
>>>and check to not allow alpha to overcome max value
>>>- Subtraction - if two colors are the same alpha becomes 0,
>>>otherwise we take alpha of message receiver (minuend)
>>>
>>> Slice is in inbox (15188)
>>>
>>> Cheers,
>>> Alex
>>>
>>>
>>
>

[Pharo-dev] Basic inspect not working

[Nicolai Hess]

Did we miss the postload for issue 15182?
Basic Inspect gives
PharoCommonTools(Object)>>doesNotUnderstand: #basicInspector

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

[Marcus Denker]

> On 22 Mar 2015, at 13:35, Nicolai Hess  wrote:
> 
> 
> 
> 2015-03-22 12:43 GMT+01:00 Nicolai Hess  >:
> 
> 
> 2015-03-21 15:51 GMT+01:00 Eliot Miranda  >:
> Why not take the average of alpha in all cases?
> 
> Eliot (phone)
> 
> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel  > 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

Re: [Pharo-dev] Basic inspect not working

[Marcus Denker]

I will open an issue.

> On 22 Mar 2015, at 13:41, Nicolai Hess  wrote:
> 
> Did we miss the postload for issue 15182?

Re: [Pharo-dev] Basic inspect not working

[Marcus Denker]

> On 22 Mar 2015, at 13:41, Nicolai Hess  wrote:
> 
> Did we miss the postload for issue 15182?
> Basic Inspect gives 
> PharoCommonTools(Object)>>doesNotUnderstand: #basicInspector
> 
> 

Yes.

Re: [Pharo-dev] Upgrading Fuel Data

[Sean P. DeNigris]

> I hope this makes image migrations a bit easier
Thanks! I’m sure it will :)





-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Upgrading-Fuel-Data-tp4809243p4814076.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] What do we do: 14198 Time>>print24 prints nanos, though it claims not to

[Marcus Denker]

Hi,

what do we do with this:

https://pharo.fogbugz.com/f/cases/14198/Time-print24-prints-nanos-though-it-claims-not-to

We intergrated it even the last comment before integrating started with
"I still don't agree totally (with the solution, I do see there is an issue).”

Do we revert it? Is is good enough?

Marcus

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

[Marcus Denker]

> On 22 Mar 2015, at 11:41, Marcus Denker  wrote:
> 
> 
>> On 22 Mar 2015, at 11:33, Ben Coman  wrote:
>> 
>> That is very cool. But I need to ask the tough question - given that the 
>> feature freeze was three weeks ago, what do we gain by adding this in Pharo 
>> 4?  
>> 
>> * Is it needed for demonstrations that won't be based off latest features in 
>> Pharo 5 ?
>> 
>> * Are third party libraries expected to be based only off Pharo 4 MetaLink 
>> features, rather than additional MetaLink features it sounds like Pharo 5 
>> will get ?
>> 
>>> which means this slice should not impact anything
>> 
>> Because "should" being the operative word... is a slippery slope. If we have 
>> a philosophy of freezing features before a Release, then we should have the 
>> discipline to hold to that - at least in last 7 days before Release.
>> 
> 
> Yes, maybe we should postpone it… releasing is boring, I have to admit :-)
> 
I will revert the change in the visitor… this way we are sure that we do not 
get any problems.

https://pharo.fogbugz.com/f/cases/15207/Undo-compiler-change-from-case-15196 


I am really looking forward to that in Pharo5… it is (one of my) largest 
mistakes that after my PhD I did not focus on
getting Reflectivity into Pharo… it is still amazing, even 5 years later, I 
think. (but I am biased ;-)

Marcus

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

[Ben Coman]

On Sun, Mar 22, 2015 at 9:24 PM, Marcus Denker 
wrote:

>
> On 22 Mar 2015, at 11:41, Marcus Denker  wrote:
>
>
> On 22 Mar 2015, at 11:33, Ben Coman  wrote:
>
> That is very cool. But I need to ask the tough question - given that the
> feature freeze was three weeks ago, what do we gain by adding this in Pharo
> 4?
>
> * Is it needed for demonstrations that won't be based off latest features
> in Pharo 5 ?
>
> * Are third party libraries expected to be based only off Pharo 4 MetaLink
> features, rather than additional MetaLink features it sounds like Pharo 5
> will get ?
>
> which means this slice should not impact anything
>
>
> Because "should" being the operative word... is a slippery slope. If we
> have a philosophy of freezing features before a Release, then we should
> have the discipline to hold to that - at least in last 7 days before
> Release.
>
>
> Yes, maybe we should postpone it… releasing is boring, I have to admit :-)
>
> I will revert the change in the visitor… this way we are sure that we do
> not get any problems.
>
>
> https://pharo.fogbugz.com/f/cases/15207/Undo-compiler-change-from-case-15196
>
> I am really looking forward to that in Pharo5… it is (one of my) largest
> mistakes that after my PhD I did not focus on
> getting Reflectivity into Pharo… it is still amazing, even 5 years later,
> I think. (but I am biased ;-)
>
> Marcus
>
>
Thanks Marcus.  It sets a good example for everyone (including me).
Anyway, its a nice bit of honey to draw more people to follow the Pharo 5
trunk ;)
cheers -ben

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

[Marcus Denker]

>> 
> I will revert the change in the visitor… this way we are sure that we do not 
> get any problems.
> 
> https://pharo.fogbugz.com/f/cases/15207/Undo-compiler-change-from-case-15196 
> 
> 
> I am really looking forward to that in Pharo5… it is (one of my) largest 
> mistakes that after my PhD I did not focus on
> getting Reflectivity into Pharo… it is still amazing, even 5 years later, I 
> think. (but I am biased ;-)
> 
>   Marcus
> 
> 
> Thanks Marcus.  It sets a good example for everyone (including me).  Anyway, 
> its a nice bit of honey to draw more people to follow the Pharo 5 trunk ;)
> cheers -ben

I will be so great that nobody will use Pharo4 ever… ;-)

Marcus

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

[Aliaksei Syrel]

>
> 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.
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.

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

Cheers,
Alex

On Sun, Mar 22, 2015 at 1:54 PM, Marcus Denker 
wrote:

>
> On 22 Mar 2015, at 13:35, Nicolai Hess  wrote:
>
>
>
> 2015-03-22 12:43 GMT+01:00 Nicolai Hess :
>
>>
>>
>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda :
>>
>>> Why not take the average of alpha in all cases?
>>>
>>> Eliot (phone)
>>>
>>> On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel 
>>> 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
>

Re: [Pharo-dev] TextMorph scrolling the text on edit or selection operations

[Johan Fabry]

Hi Ben,

It’s noticeable if you use small windows a lot, like I do. I guess you must 
have a bigger screen than mine ;-)

There is a description halfway down the thread on how to reproduce it, just 
before I uploaded the slice. Date is 19/08/2014 

 

> On Mar 22, 2015, at 09:00, Ben Coman  wrote:
> 
> Can't say that I noticed it.  There is no information on that issue on how to 
> reproduce it. Sounds like you've got two use cases.  Can you provide some 
> specific examples of these so I can observe the behaviour.  
> cheers -ben
> 
> On Sun, Mar 22, 2015 at 3:19 AM, Johan Fabry  > wrote:
> Hi all,
> 
> I am assuming that I am not the only one that gets very annoyed when a 
> TextMorph scrolls the text when typing, such that the line I am typing is 
> always at the bottom, or scrolls the debugger when I am stepping over 
> instructions. I looked into this (bug
> https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-when-accepting-text
>  
> 
>  actually) and I found a fix.
> 
> But first I want to understand why the code is as it is. Anybody have any 
> idea why PluggableTextMorph>>setTextBasic: starts with scrollBar setValue: 
> 0.0. ?? If I remove this line the very annoying behavior is gone, and as far 
> as I can see there are no negative consequences on text handling (and 
> scrolling) in general. So I am wondering why it is there at all.
> 
> A slice with my fix is in the inbox if you want to play a bit with it: 
> SLICE-Issue-12569-TextModel-should-not-move-scroll-when-accepting-text-johanfabry.1
> 
> Please have a look, this behavior has been getting on my nerves for quite 
> some time now …
> 
> 
> ---> Save our in-boxes! http://emailcharter.org  
> <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry 
> PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile
> 
> 
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-dev] TextMorph scrolling the text on edit or selection operations

[Johan Fabry]

It would be very good to have a full test suite for Spec, but unit tests for UI 
stuff is complicated :-/

> On Mar 21, 2015, at 18:06, Peter Uhnák  wrote:
> 
> Also even though this was morphic issue, perhaps we should start adding tests 
> for spec since there are none. :(



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

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

[kilon alios]

wait a sec why Alpha affects the Color ? o_O


Color white - (Color white alpha:0.5) = Color gray.

What ? No ! This make no sense


Color white - (Color white alpha:0) = Color white

Ok reasonable


Color white - (Color white alpha:1.0) = Color black.
again reasonable




On Sun, Mar 22, 2015 at 4:06 PM, Aliaksei Syrel 
wrote:

> 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.
> 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.
>
> 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
>
> Cheers,
> Alex
>
> On Sun, Mar 22, 2015 at 1:54 PM, Marcus Denker 
> wrote:
>
>>
>> On 22 Mar 2015, at 13:35, Nicolai Hess  wrote:
>>
>>
>>
>> 2015-03-22 12:43 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda :
>>>
 Why not take the average of alpha in all cases?

 Eliot (phone)

 On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel 
 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
>>
>
>

Re: [Pharo-dev] [Reflectivity] simple #before and #after links working...

[Tudor Girba]

Indeed, it is an amazing piece of work :).

Doru

On Sun, Mar 22, 2015 at 2:58 PM, Marcus Denker 
wrote:

>
>> I will revert the change in the visitor… this way we are sure that we do
>> not get any problems.
>>
>>
>> https://pharo.fogbugz.com/f/cases/15207/Undo-compiler-change-from-case-15196
>>
>> I am really looking forward to that in Pharo5… it is (one of my) largest
>> mistakes that after my PhD I did not focus on
>> getting Reflectivity into Pharo… it is still amazing, even 5 years later,
>> I think. (but I am biased ;-)
>>
>> Marcus
>>
>>
> Thanks Marcus.  It sets a good example for everyone (including me).
> Anyway, its a nice bit of honey to draw more people to follow the Pharo 5
> trunk ;)
> cheers -ben
>
>
> I will be so great that nobody will use Pharo4 ever… ;-)
>
> Marcus
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

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

[Aliaksei Syrel]

On Sun, Mar 22, 2015 at 3:31 PM, kilon alios  wrote:

> Color white - (Color white alpha:1.0) = Color black.
> again reasonable


No, it's not really reasonable ;)

> (Color white alpha: 1.0) = Color white => true


I personally assume to get Color transparent when subtract two absolutely
equal colors.
And by the way there is no way in pharo to detect that they could be not
equal:

 (Color white alpha: 1.0) != Color white

Color white - (Color white alpha:1.0)

The same as

> Color white - Color white



Cheers,
Alex

[Pharo-dev] 15097 thx Re: [pharo-project/pharo-core] 93eb5c: 40571

[Ben Coman]

On Sat, Mar 21, 2015 at 1:02 AM, GitHub  wrote:

>   Branch: refs/heads/4.0
>   Home:   https://github.com/pharo-project/pharo-core
>   Commit: 93eb5ced08fb721a2448d25cdb6264468e083569
>
> https://github.com/pharo-project/pharo-core/commit/93eb5ced08fb721a2448d25cdb6264468e083569
>   Author: Jenkins Build Server 
>   Date:   2015-03-20 (Fri, 20 Mar 2015)
>
>   Log Message:
>   ---
>   40571
> 15097 Monticello repository UI not bolding unloaded packages after Lazy
> MCVersionInfo integrated
> https://pharo.fogbugz.com/f/cases/15097
>
>
I did not get a chance to review 15097 before it was integrated, but it was
just what I was looking for. Thanks Thierry and Marcus.
cheers -ben

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

[kilon alios]

"I personally assume to get Color transparent when subtract two absolutely
equal colors."

why ? that makes no sense to me. I guess we reason about things
differently. In art black and white are not colors, they are called
"neutrals" and they have the meaning of the existence of light (white) and
non existence of light (black) as such black has the meaning of zero.
Transparency does not affect colors its a characteristic of materials by
allowing some of the light to pass through.

In my view for arithmetical operation transparency should be ignored and
operate only on the color itself.

Re: [Pharo-dev] Basic inspect not working

[stepharo]

Yes I missed it.

Le 22/3/15 13:55, Marcus Denker a écrit :

On 22 Mar 2015, at 13:41, Nicolai Hess  wrote:

Did we miss the postload for issue 15182?
Basic Inspect gives
PharoCommonTools(Object)>>doesNotUnderstand: #basicInspector



Yes.

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40575
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 099b5e: 40575

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 099b5e013de5b9a4e684df472a49ff5be8b13f68
  
https://github.com/pharo-project/pharo-core/commit/099b5e013de5b9a4e684df472a49ff5be8b13f68
  Author: Jenkins Build Server 
  Date:   2015-03-22 (Sun, 22 Mar 2015)

  Changed paths:
M 
Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st
M 
ReleaseTests.package/ObsoleteTest.class/instance/tests/testClassObsolete.st
M 
ReleaseTests.package/ObsoleteTest.class/instance/tests/testFixObsoleteSharedPools.st
M 
ReleaseTests.package/ObsoleteTest.class/instance/tests/testTraitObsolete.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script574.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script575.st
R ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40574.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40575.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40575
15206 PostScript was not executed for issue 15182?
https://pharo.fogbugz.com/f/cases/15206

15203 Failing test: PackageTreeNautilusTest>>#testFullBrowseOnClass
https://pharo.fogbugz.com/f/cases/15203

14470 ReleaseTes>>#testObsoleteClasses failiing due to 
AnObsoleteClassForObsoleteTest
https://pharo.fogbugz.com/f/cases/14470

http://files.pharo.org/image/40/40575.zip

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

[Marcus Denker]

44!

> On 20 Mar 2015, at 20:17, Marcus Denker  wrote:
> 
> 52. Much better!
> 
> some are even already fixed (but not integrated) so we will be below 50 soon.
> 
>> On 20 Mar 2015, at 10:11, Marcus Denker  wrote:
>> 
>> 68
>> 
>>> On 19 Mar 2015, at 08:50, Marcus Denker  wrote:
>>> 
>>> 88.
>>> 
>>> https://pharo.fogbugz.com/f/filters/103/4-0-All
>>> 
>> 
>> 
> 

Re: [Pharo-dev] [Pharo4] 203 issues tagged tagged for Pharo4

[Tudor Girba]

Hey, please slow down. In this rhythm we will be done way before the
release date :))

Doru

On Sun, Mar 22, 2015 at 7:29 PM, Marcus Denker 
wrote:

> 44!
>
> > On 20 Mar 2015, at 20:17, Marcus Denker  wrote:
> >
> > 52. Much better!
> >
> > some are even already fixed (but not integrated) so we will be below 50
> soon.
> >
> >> On 20 Mar 2015, at 10:11, Marcus Denker  wrote:
> >>
> >> 68
> >>
> >>> On 19 Mar 2015, at 08:50, Marcus Denker 
> wrote:
> >>>
> >>> 88.
> >>>
> >>> https://pharo.fogbugz.com/f/filters/103/4-0-All
> >>>
> >>
> >>
> >
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

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

[Nicolai Hess]

2015-03-22 15:06 GMT+01:00 Aliaksei Syrel :

> 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 
> wrote:
>
>>
>> On 22 Mar 2015, at 13:35, Nicolai Hess  wrote:
>>
>>
>>
>> 2015-03-22 12:43 GMT+01:00 Nicolai Hess :
>>
>>>
>>>
>>> 2015-03-21 15:51 GMT+01:00 Eliot Miranda :
>>>
 Why not take the average of alpha in all cases?

 Eliot (phone)

 On Mar 21, 2015, at 6:32 AM, Aliaksei Syrel 
 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
>>
>
>

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

[Nicolai Hess]

2015-03-21 23:14 GMT+01:00 Peter Uhnák :

> 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/validationReport.html
>
> 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
>

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

[Aliaksei Syrel]

On Sun, Mar 22, 2015 at 8:17 PM, Nicolai Hess  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

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

[Nicolai Hess]

2015-03-22 21:26 GMT+01:00 Aliaksei Syrel :

>
> On Sun, Mar 22, 2015 at 8:17 PM, Nicolai Hess  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 
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
>

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

[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

[Pharo-dev] UI Workflows Are Like Snowflakes

[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.

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

[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

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

[Marcus Denker]

> On 22 Mar 2015, at 22:56, Dale Henrichs  
> 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

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

[Marcus Denker]

> On 22 Mar 2015, at 23:41, Sean P. DeNigris  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

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

[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.