On Sat, Mar 26, 2016 at 9:19 AM, stepharo <steph...@free.fr> wrote: > > I want a clean and stable core. > > > me too. > Now you will not my core. Because there is no UI no announcement... > > The way Rubric and GT-Tools were pushed into the core was a mess. > > > No I cannot let you to say that. I'm sorry. We spent 4 months cleaning > Nautilus > and Rubric is not optimal but we decided that forcing to adapt to Rubric > was a good move > for the next one. We did it to help > - breakpoints > - QA feedback > > Rubric was pushed in Pharo over the summer. So if we cannot change > something as important that > that more than 8 months before the release then we should better stop to > do pharo. > Because for Rubric ***I*** planned it in advance with a stabilisation > phase. > Now Pharo 50 got far too many new features > > We should have not include > Spur and release Pharo 50 without it > and keep new FFI and Spur for Pharo 60 > and keep GTTools for Pharo 60 > > If this is your analysis then we are ok. Now you cannot tell me that > pushing rubric was a mess. > The state of the system (in particular the lack of good widgets) is a > problem. > Look at the keybindings why the keybinding is still the mess: simply > because all the widgets and tools > just nicely harcoded them. > It does not mean that we should not fix them but you cannot > fight day long against spur migration bugs > fight day long against FFI glitches > fix integration bugs of GT > and get more steam for the rest > > Now let me tell you frankly I prefer to build useless mini new languages > than fighting with ugly widgets > so why did I supervised and worked with a guy to improve and push rubric? > Because it was needed. > > Rubric is a big bad bunch of badly documented code > > indeed it is badly documented. Now it has examples. > Now synectique and moose have been using in their product rubric. > > with lots of copy-paste garbage - we should do better. > And since it was included I hear it was abandoned by alain > > No alain helped each time we asked him but he has severe family problems > (the kind of problems that you do not > want to have but you have to face). > > and TxText is the next. > > What can we say? > I have no idea why igor disappeared and kind of divorced. > Now the design of TxText is nice and we will have to invest. Bricks > already used it and people looking > at it mentioned that it is good. > So the objectives is to drop rubric (because it is a hack and we know it > but a hack which supports embellisment and icons) > and use TxText. > > I see up to no development for TxText. > The same for Athens, bugs or requests for conclusins I entered in FogBugz > are, or will be closed (timout) > because no one cares. > > But you see you are becoming the most aware for athens > and what we should do is document document. > Now I got ****EXHAUSTED**** to document things that I did not build or use > daily. This effort for me is gigantic > and I cannot do it each time. > > Instead Athens is used as it is or change by others just for its own > projects (roassal, Bloc, Brick). > > Do you think that roassal is extended privately Athens. I would be > surprised. > I know that we all like what you did with the widgets because blocers can > work in athens with default widgets > and our goal is to throw all the morphic layer away and only use Athens. > > Now we should give feedback to blocers > > > > >> >> I personnally want to have new widgets, a real UI builder and massively >> cleaning Spec. >> > > me too, but what is the purpose of spec, if we replace all tools based on > spec (debugger/inspector/...) with GT-Tools? > > > We need a UI Builder and spec is a way to build widgets. > Now before we get the perfect solution we need to make sure that we clean > it. > I would like to do that with Peter. > But again there is no magic: some part of spec are ugly because of design > but others are ugly > because the widgets are poor. > > Now for me I have no problem cleaning Spec even if at the end we replace > it by something else. > We did that for the compiler, we are doing it for Morphic, .... > > > > >> Now I would like to have multiple tool sets - I understand that people >> like the new debugger (I do not like it) - >> I want the possibility to have a mini tools tool set. >> >> If you want to clean Pharo >> > > I fix bugs, there are many bugs. > > > I know nicolai and I understand your frustration and I understand it:) > I thank you everyday for that. > I think that we should remove things from Pharo > So the most important point for us is to get in place a process so that we > can avoid to get monolithic again > For example we need a process to have the possibility to remove project > from the image and still build and modify an image with them. > It will not change the problem that when a bug is there we have a bug but > it should lower the stress. > > you can start cleaning Komitter stupid use of state pattern generating >> a lot of garbage instead of having a single animated morph. >> >> We should clean Versionner- I have the impression that half of the >> classes are not mandatory. >> >> > Our tools are in a much more worse state than in Pharo 4, not clean, not > stable. > > Where? > Nautilus is much better to me. > I used Versionner and it is working. > CodeCritics > > I got some glitches with refactorings > > Do you have some issues? > > We are in code freeze since 6 weeks, and there are still many new changes > instead of only bug fixes. > > I thought that it was not the case and I do not think so. > So this is side effect of the cleaning of foundations. > The problems is that we cannot block people working on the bootstrap > forever. > > > So nicolai what I would do is a roadmap for Pharo 60 > - there will be no Spur and FFI :) > - so it will be consolidation > - I would like to have release every six months (but it should be > discussed) > - for me I would like to have > - cleaning Spec > - cleaning another time nautilus > - cleaning versionner > - cleaning Komitter > - Now we have epicea waiting > - So Xtreams will be probably for later. > > This is just too much indeed. But we are learning a lot by doing this.
Phil
