Sean Iâm trying to understand how we could work together to share forces on cleaning morphic. Now it is not easy because some of the changes are crosscutting many packages. If somebody has an idea. Stef
Hi, I would be interested in seeing what kind of tools could help us. So, let's start by making explicit the kinds of things we are looking for and I can try to build some tools for it. Doru On Sat, Jan 25, 2014 at 10:30 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Sean Iâm trying to understand how we could work together to share forces on cleaning morphic. Now it is not easy because some of the changes are crosscutting many packages. If somebody has an idea.
Stef
-- www.tudorgirba.com "Every thing has its own flow"
I've spent a considerable amount of time fighting with Morphic trying to get TouchUI and Athens rendering working. Based on that, my feeling is that getting Athens thoroughly integrated into Morphic is key. The way Morphic used to work is that a morph would signal itself as changed, marking its bounds as needing to get redrawn. Once a UI cycle, all the dirty areas would get summed together and any morphs within those bounds would be asked to redraw. Part of the way this worked is by using a clipping canvas. Thus, a morph could decide whether it or its submorphs needed to get drawn based on the clipping area. This was a quite efficient process. Using AthensWrapMorph to move my applications to Athens, I've seen how the speed advantages of Athens can disappear without such a process. Since there is no clipping canvas, all morphs get redrawn for each draw cycle. Compounding the problem, each changed message triggers a redraw. While Athens rendering can be blazingly fast, doing it 48 (actual number for one of my apps) times as many times as necessary does make it seem slow. Another problem is with animation. Athens gives us the possibility to do some really nice animations. So far, I haven't found a way to do these in a way where it doesn't block out the interface. Having support for animations that don't slow down the interface would be a great ground competency to have for Morphic. To me, integrating Athens thoroughly into Morphic and allowing Morphic to take advantage of the speed and flexibility is the next step. After that, event handling should be addressed. Debugging events is a giant pain and part of it is that there is a ton of reflection and event handling happening in an event handler rather than the object itself. Sometimes it isn't clear how the event handler is being created and trying to figure out where something is set becomes frustrating. Anyway, that's my experience. Jeff On Sat, Jan 25, 2014 at 10:30 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Sean Iâm trying to understand how we could work together to share forces on cleaning morphic. Now it is not easy because some of the changes are crosscutting many packages. If somebody has an idea.
Stef
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Jeff, just wondering: would it make sense to have all the events processes in a new host window? For most of the thing we are doing with visualization, having an external host window will not be a problem, and as far as I can see, this may solve many problem related to io/events/... Alexandre On Jan 26, 2014, at 1:55 PM, J.F. Rick <self@je77.com> wrote:
I've spent a considerable amount of time fighting with Morphic trying to get TouchUI and Athens rendering working. Based on that, my feeling is that getting Athens thoroughly integrated into Morphic is key. The way Morphic used to work is that a morph would signal itself as changed, marking its bounds as needing to get redrawn. Once a UI cycle, all the dirty areas would get summed together and any morphs within those bounds would be asked to redraw. Part of the way this worked is by using a clipping canvas. Thus, a morph could decide whether it or its submorphs needed to get drawn based on the clipping area. This was a quite efficient process.
Using AthensWrapMorph to move my applications to Athens, I've seen how the speed advantages of Athens can disappear without such a process. Since there is no clipping canvas, all morphs get redrawn for each draw cycle. Compounding the problem, each changed message triggers a redraw. While Athens rendering can be blazingly fast, doing it 48 (actual number for one of my apps) times as many times as necessary does make it seem slow.
Another problem is with animation. Athens gives us the possibility to do some really nice animations. So far, I haven't found a way to do these in a way where it doesn't block out the interface. Having support for animations that don't slow down the interface would be a great ground competency to have for Morphic.
To me, integrating Athens thoroughly into Morphic and allowing Morphic to take advantage of the speed and flexibility is the next step. After that, event handling should be addressed. Debugging events is a giant pain and part of it is that there is a ton of reflection and event handling happening in an event handler rather than the object itself. Sometimes it isn't clear how the event handler is being created and trying to figure out where something is set becomes frustrating.
Anyway, that's my experience.
Jeff
On Sat, Jan 25, 2014 at 10:30 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Sean Iâm trying to understand how we could work together to share forces on cleaning morphic. Now it is not easy because some of the changes are crosscutting many packages. If somebody has an idea.
Stef
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Pharo4Stef wrote
Iâm trying to understand how we could work together to share forces on cleaning morphic.
Yes, this will be my focus for 4.0 and I've been thinking a lot about it. I've spent the last few weeks studying Cuis, Self, and the L and KS stuff from vpri. These are some of the experiments I want to do: 1. infinite world a la Self 2. remove all global references i.e. ActiveWorld, World, and ActiveHand 3. possible remove the concept of mouse and keyboard focus entirely. This is what Self does and it seems much cleaner. There would just be mouse and keyboard subscribers and a Morph, let's say a text editor, would "take focus away from itself" e.g. when there was a mouseDown outside it's bounds 4. Local co-ordinates 5. Simplified layouts (maybe based on Cuis or Lesserphic) 6. Cuis CPU-saving UI loop 7. Direct Morph construction leading to e.g. Spec models I don't think the cross-cutting problem will be so bad because there doesn't seem to be much work at this low-level. So our slices will go stale, but should be easily merge-able. I think the safest way to proceed would be: 1. Hypothesis - write up our ideas about how Morphic currently works 2. Experiment - write tests for the current behavior Once we have a theory about existing Morphic, we can repeat. e.g. 3. Hypothesis - coordinates should be local to owner Morph 4. Experiment - pick a Morph far from core i.e. nothing used in development tools and apply. See how it works, if it makes things more clear Now hopefully we'll have a theory that local coordinates will improve the system, and we apply it to the whole system: 5. Set up a hook to easily plug the new behavior in and out. e.g. (pseudo code) NewClass class>>#enable Smalltalk at: #ExistingClass put: NewClass NewClass class>>#disable Smalltalk at: #ExistingClass put: OldClass "where OldClass is a class var" Maybe we can even put an error handler in the UI loop so that errors automatically unplug the new code. Anyway, just some preliminary ideas... ----- Cheers, Sean -- View this message in context: http://forum.world.st/process-to-collaborate-on-cleaning-morphic-tp4739325p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Sun, Jan 26, 2014 at 9:48 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
3. possible remove the concept of mouse and keyboard focus entirely. This is what Self does and it seems much cleaner. There would just be mouse and keyboard subscribers and a Morph, let's say a text editor, would "take focus away from itself" e.g. when there was a mouseDown outside it's bounds
Interesting. One thing to consider is support for (or non-exclusion of) soft keyboards. In a tabletop setup, you could have multiple keyboards, each with a different focus (or list of subscribers). Same thing for mouse input. There could be systems with more than one mouse or, more likely, multi-touch input. I've been using Squeak / Pharo for fairly novel devices for some time and having the flexibility to augment the events, etc. has been really useful. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Sean this is years since I clean Morphic (may be Iâm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea? For example I have remove extract update conditional leaves into method, remove update/changed from leave morph. in your list you have items that should be first validated by an experience. And it would be good to distinguish them from the others.
Pharo4Stef wrote
Iâm trying to understand how we could work together to share forces on cleaning morphic.
Yes, this will be my focus for 4.0 and I've been thinking a lot about it. I've spent the last few weeks studying Cuis, Self, and the L and KS stuff from vpri.
These are some of the experiments I want to do: 1. infinite world a la Self 2. remove all global references i.e. ActiveWorld, World, and ActiveHand 3. possible remove the concept of mouse and keyboard focus entirely. This is what Self does and it seems much cleaner. There would just be mouse and keyboard subscribers and a Morph, let's say a text editor, would "take focus away from itself" e.g. when there was a mouseDown outside it's bounds
I do not know
4. Local co-ordinates
We talk with Alain and Nicolas and one idea could be to introduce a Morph in Bloc (composite) that has local coordinate but still offer a global computation so that we can slowly migrate code to the local
5. Simplified layouts (maybe based on Cuis or Lesserphic) 6. Cuis CPU-saving UI loop 7. Direct Morph construction leading to e.g. Spec models
I did not get 7 Remove update:/changed:
I don't think the cross-cutting problem will be so bad because there doesn't seem to be much work at this low-level. So our slices will go stale, but should be easily merge-able.
I think the safest way to proceed would be: 1. Hypothesis - write up our ideas about how Morphic currently works 2. Experiment - write tests for the current behavior Once we have a theory about existing Morphic, we can repeat. e.g. 3. Hypothesis - coordinates should be local to owner Morph 4. Experiment - pick a Morph far from core i.e. nothing used in development tools and apply. See how it works, if it makes things more clear Now hopefully we'll have a theory that local coordinates will improve the system, and we apply it to the whole system: 5. Set up a hook to easily plug the new behavior in and out. e.g. (pseudo code) NewClass class>>#enable Smalltalk at: #ExistingClass put: NewClass NewClass class>>#disable Smalltalk at: #ExistingClass put: OldClass "where OldClass is a class var" Maybe we can even put an error handler in the UI loop so that errors automatically unplug the new code.
Anyway, just some preliminary ideas...
----- Cheers, Sean -- View this message in context: http://forum.world.st/process-to-collaborate-on-cleaning-morphic-tp4739325p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 28/01/2014 18:41, Pharo4Stef a écrit :
this is years since I clean Morphic (may be Iâm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea?
What about a brutal scheme, independent of all code quality considerations: - dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy. I guess Steph already did some of this in the past. The idea is you don't want to refactor unused code, right? -- Dr. Geo http://drgeo.eu
2014-01-29 Hilaire Fernandes <hilaire.fernandes@gmail.com>
Le 28/01/2014 18:41, Pharo4Stef a écrit :
this is years since I clean Morphic (may be I'm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea?
What about a brutal scheme, independent of all code quality considerations:
- dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy.
I guess Steph already did some of this in the past.
The idea is you don't want to refactor unused code, right?
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal. Cheers, -- Pavel
-- Dr. Geo http://drgeo.eu
Know what would be making it really useful? A nice dark theming feature. Yeah, that's not Morphic-Core, but currently, this aspect makes the whole thing feel stuck in the 90's. Esteban, did you had any luck with that? Phil On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
2014-01-29 Hilaire Fernandes <hilaire.fernandes@gmail.com>
Le 28/01/2014 18:41, Pharo4Stef a écrit :
this is years since I clean Morphic (may be I'm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea?
What about a brutal scheme, independent of all code quality considerations:
- dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy.
I guess Steph already did some of this in the past.
The idea is you don't want to refactor unused code, right?
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal.
Cheers, -- Pavel
-- Dr. Geo http://drgeo.eu
On 29 Jan 2014, at 15:50, phil@highoctane.be wrote:
Know what would be making it really useful?
A nice dark theming feature.
Yeah, that's not Morphic-Core, but currently, this aspect makes the whole thing feel stuck in the 90's.
Esteban, did you had any luck with that?
not yet :( time time time time :(( Doru was going to help on that too⦠but I think he is the same situation as me. Esteban
Phil
On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2014-01-29 Hilaire Fernandes <hilaire.fernandes@gmail.com> Le 28/01/2014 18:41, Pharo4Stef a écrit :
this is years since I clean Morphic (may be Iâm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea?
What about a brutal scheme, independent of all code quality considerations:
- dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy.
I guess Steph already did some of this in the past.
The idea is you don't want to refactor unused code, right?
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal.
Cheers, -- Pavel
-- Dr. Geo http://drgeo.eu
Yeah, time. Not enough not enough not enough. Who is going to be at #FOSDEM on Saturday? Phil On Wed, Jan 29, 2014 at 3:58 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
On 29 Jan 2014, at 15:50, phil@highoctane.be wrote:
Know what would be making it really useful?
A nice dark theming feature.
Yeah, that's not Morphic-Core, but currently, this aspect makes the whole thing feel stuck in the 90's.
Esteban, did you had any luck with that?
not yet :( time time time time :((
Doru was going to help on that too... but I think he is the same situation as me.
Esteban
Phil
On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
2014-01-29 Hilaire Fernandes <hilaire.fernandes@gmail.com>
Le 28/01/2014 18:41, Pharo4Stef a écrit :
this is years since I clean Morphic (may be I'm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea?
What about a brutal scheme, independent of all code quality considerations:
- dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy.
I guess Steph already did some of this in the past.
The idea is you don't want to refactor unused code, right?
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal.
Cheers, -- Pavel
-- Dr. Geo http://drgeo.eu
On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph.
There's a question of what is necessary for a modern GUI core. To me, we need to get out of BitBlt rendering completely and towards vectors. Reliance on BitBlt makes Pharo seem slow and outdated. Pixelation is so early 1990s. Novices also don't understand that a slow GUI isn't indicative of everything being slow. There's no reason Pharo's UI can't be fast enough that you can't tell the difference between it and a native app. That would do a lot to make Pharo more palatable to newcomers. First impressions are critical. We should also make it easy for people to build animations and build them into the core tools (when it makes sense). Most modern OSs feature great support for animation. Even if these things are largely eye candy, they do change people's perceptions. I'd love to be able to do something like this: aMorph resizeToBounds: (100 @ 100 extent: 200 @ 200) inSeconds: 2. Speaking of which, it would be nice if orientation could be included into the equation. Perhaps support for affine transforms would be standard. There also should be substantial support for vector graphics. The Athens SVG input is a good step forward, but I'd like to see something that seems very Pharo-native and that can be exported to SVG, rather than something that seems very close to SVG XML (as is now the case). Ideally, I'd like to do the old demo of rotating a browser and still using it but have it still look smooth (i.e., no pixelation). Another thing to perhaps address is how morphs are controlled and resized. Currently, when we change the extent, then the top left corner remains the same. For most cases, keeping the center the same would be more intuitive; vvvv does that and is fairly easy for programming novices to use. It would also allow us to combine rotation and scaling in some ways: aMorph rotateAndScaleBottomLeftTo: 300 @ 20. "keep the center stationary" Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 29 Jan 2014, at 16:37, J.F. Rick <self@je77.com> wrote:
On Wed, Jan 29, 2014 at 3:36 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote: I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph.
There's a question of what is necessary for a modern GUI core. To me, we need to get out of BitBlt rendering completely and towards vectors. Reliance on BitBlt makes Pharo seem slow and outdated.
+ 1 This is why I asked igor to work on Athens and we are nearly there. We need this ^%^%&^( texteditor and to move the morph to drawOnAtehns however it will not come automagically. When ronie will be back in chile Igor and christophe should pay program on the text editor.
Pixelation is so early 1990s. Novices also don't understand that a slow GUI isn't indicative of everything being slow. There's no reason Pharo's UI can't be fast enough that you can't tell the difference between it and a native app. That would do a lot to make Pharo more palatable to newcomers. First impressions are critical.
+ retina :)
We should also make it easy for people to build animations and build them into the core tools (when it makes sense). Most modern OSs feature great support for animation. Even if these things are largely eye candy, they do change people's perceptions. I'd love to be able to do something like this: aMorph resizeToBounds: (100 @ 100 extent: 200 @ 200) inSeconds: 2.
Did you check Viva on petitsBazars on my repo because this is proto that igor built for a GSOC project (that failed)
Speaking of which, it would be nice if orientation could be included into the equation. Perhaps support for affine transforms would be standard. There also should be substantial support for vector graphics. The Athens SVG input is a good step forward, but I'd like to see something that seems very Pharo-native and that can be exported to SVG, rather than something that seems very close to SVG XML (as is now the case). Ideally, I'd like to do the old demo of rotating a browser and still using it but have it still look smooth (i.e., no pixelation).
Yes I think that this is already possible (but without text)
Another thing to perhaps address is how morphs are controlled and resized. Currently, when we change the extent, then the top left corner remains the same. For most cases, keeping the center the same would be more intuitive; vvvv does that and is fairly easy for programming novices to use. It would also allow us to combine rotation and scaling in some ways: aMorph rotateAndScaleBottomLeftTo: 300 @ 20. "keep the center stationaryâ
I (with esteban) already cleaned the margin mess by introducing Margin and it cleaned some code. We cleaned a lot 200 users of layoutFrame with Igor. Nobody noticed it but we fixed a lot of code. Stef
Cheers,
Jeff
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
I'd love to be able to do something like this: aMorph resizeToBounds: (100 @ 100 extent: 200 @ 200) inSeconds: 2. Speaking of which, it would be nice if orientation could be included into the equation.
Roassal2 will exactly feature this. E.g., -=-=-=-=-=-=-=-=-=-= | e v | v := RTView new. e := (RTBox new color: Color green; width: 150; height: 120) element. v add: e. e when: TRMouseClick do: [ :evt | | anim | anim := RTResizeMove new toExtent: (50 @ 30) during: 3 on: e. v addAnimation: anim. ]. e @ RTDraggable. v open -=-=-=-=-=-=-=-=-=-= 3 means the time taken by the square to shrink. This is based on the work of Viva. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
We will get there :) Stef On 29 Jan 2014, at 15:36, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
2014-01-29 Hilaire Fernandes <hilaire.fernandes@gmail.com> Le 28/01/2014 18:41, Pharo4Stef a écrit :
this is years since I clean Morphic (may be Iâm that good at it) but this is important to go step by step. So I would really like to get a list of simple actions. Do you have an idea?
What about a brutal scheme, independent of all code quality considerations:
- dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal - mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy.
I guess Steph already did some of this in the past.
The idea is you don't want to refactor unused code, right?
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal.
Cheers, -- Pavel
-- Dr. Geo http://drgeo.eu
w
What about a brutal scheme, independent of all code quality considerations:
- dedicate a Pharo release process *only* to Morphic cleaning so people will know it gona be brutal
This is not that easy. Because we should really learn about morph internals. And this what we were planning to do with fernando but he left. and we had to reorganise. stef
- mark as deprecated all morphic methods unsused in the system. When a client (like me with DrGeo), use some of the deprecated method, fill a bug ticket, then discussion should arise about what to do: i. unmark it as deprecated ii. move it in external package iii. adoption by the client in its application code - do the same with unused classes from the Morph hierarchy.
I guess Steph already did some of this in the past.
The idea is you don't want to refactor unused code, right?
I would like to continue in the direction started with the Morphic-Core. It's a subset of Morphic that is able to be loaded into a headless image, initialize itself and show world with one basic responsive morph. We can clean it and continue with basic fonts support, windows support etc. Every step will produce one package that can be loaded on top others, will heave well defined dependencies, will be small in size, easier to understand, maintain and refactor. It looks hard but in fact it is not so horrible. In one of my previous testing image I was able to reach the state where Morphic-Core was clear - generated no new unimplemented classes and similar mess. We only need to define it as a common goal.
Cheers, -- Pavel
-- Dr. Geo http://drgeo.eu
Pharo4Stef wrote
Because we should really learn about morph internals.
Yes, it's more than cleaning. There has been so much stuff tacked on to the basic beautiful idea of Morphic that it's hard to tell what it currently does and what it needs to do. That's why as a first step, I'm learning several Morphic implementations - Lively Kernel, Cuis, Self - as well as the new VPRI work, to understand what the core is and what the options are. I'm not against cleaning, but I believe it will take work from both sides - cleaning what we have, and building/reorganizing the core ideas. ----- Cheers, Sean -- View this message in context: http://forum.world.st/process-to-collaborate-on-cleaning-morphic-tp4739325p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 30 Jan 2014, at 15:53, btc@openinworld.com wrote:
I was going to say... As an alternative to nibbling at the edges of Morphic, now that we have PharoKernel3.0-FromTopShrink, which presumably unloads Morphic, I wonder what is involved in loading Juan's SimpleMorphic [1] & [2]
...but actually it looks like SimpleMorphic was already integrated in 2010 [3]. (I'd be curious if someone could provide a summary of that.)
The problem is that is was in there and the not used. There was no idea how to migrate from one to the other.
However perhaps the idea still applies since 2010 Juan seems to have improved Morphic further [4].
The problem is that it is his thing. He does it for Cuis, not for Pharo. Itâs always a bad idea to try to run after someones stuff if that someone has other plans (e.g. that happened with Tweak, too) Marcus
participants (11)
-
Alexandre Bergel -
btc＠openinworld.com -
Esteban Lorenzano -
Hilaire Fernandes -
J.F. Rick -
Marcus Denker -
Pavel Krivanek -
Pharo4Stef -
phil＠highoctane.be -
Sean P. DeNigris -
Tudor Girba