Oh, If your goal is to remain popular, then indeeed, you should keep away from changing such parts of the system which are not shining ;). The obvious reason is that multilayer hacks with obfuscated contracts are not maintanable... so it's inevitable to create bugs in the transition and harvest complaints...
Of course, if your goal is to make the system more simple and maintanable, I'm with you (and I know it is).
Yes and this is excellent :)
But don't forget to extract the positive part of complaints that will help you making the system better.
Personnally, the finite state machine logic in Squeak/MouseOverHandler is well beyond my understanding.
:) me too but we will learn it. I started to read the code of the event handler last year and regularly I take notes and slowly I understand better.
So I could not clean it easily myself,
A cosmetic cleaning was attempted in Pharo.I have nothing against that. I just pointed a problem in current cleaning, so it just have to be finished. The stincky ivar mutation already was in Squeak. I just said that it should raise an alarm in coder's eyes in the future and I hope this helps.
Yes of course. My remark was not on that part of your message :) So can you open a bug entry so that we do not forget to change it.
Otherwise I can also shut up.
The second approach suggested by Igor is more involving, consist in a full rewrite, probably with these stages: - gather description of the features to be supported, - an inventory of third party interested in this kind of features, - and from there, decline a new definition of contracts.
Yes we will attack from all angles and slowly but steadily do it. For example, there is in a image a check to reduce event but this is not clear that the VM generate them. so we will check that first.
But please, don't do it blindly and loose 2 third of features like the new implementors window :(
We are not doing things blindly:
First it costs us money, time and we should all the lucky that Ben was really good and enjoy rewriting us boring UI without a decent widgets set (because he fixed them also the multiselection and others). Benjamin I publicly thank you for all the good stuff you did!!!!
Second, what are these 2 thirds that we lost? Because two third is a lot. I'm dreaming to throw away two third of the stringHolder hierarCrap Please hightlight me.
Sorry but I do not like this kind of statements because there are false and because we work hard to bring to life a system full of shit. Shit that was accumulated and of course stable because it did not move since years. In addition if everytime a guy spend 4 months to build a new tools we all complain (without constructive points to help him fixing that) better say to students that they are idiots and that we do not need their help. But in that case be ready to be with the same ugly system in the future. And we do not accept that. So there will be some glitches but we are stronger than them and we will fix them.
Nicolas I'm quite sure that you would not say that around a beer to benjamin because I know you so pay attention because Ben is also one of the coolest students we got recently and we really liked his spirit and atttitude. Jumping in StringHolder and broken/duplicated widgets is not easy, nor it is to work on bootstrapping Pharo.
Stef
Sure, I don't want to restrain goodwill. But as a user of the service I don't see all the sweat the hardworkers put into the system, I just see a regression that makes my life harder (I simply cannot track the messages with the new windows).
Explain us. Because we want the tools to be excellent.
And obviously, comparing the length of old menu with new one, two third does not seem exagerated to me. But maybe you don't work with those tools and install OB/RB after each update...
No I always use the core image with no tool loaded. What was on the menu? What is useful? I never use the menus?
Nicolas
Nicolas
-- Best regards, Igor Stasenko AKA sig.