Pharo Development Robustness (was: Why Bloc?)
The most important items on our IU Experience agenda - Tx and Bloc - are totally reliant on two (brilliant, talented...) programmers while the rest of the community hopes and waits. In no way to I lack appreciation for Alain and Igor's efforts, but this does not seem like a robust or efficient use of our manpower... So, I guess what I'm really asking for both projects is - how can we help? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Development-Robustness-was-Why-Bloc-tp4774980.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
The following are great starting points, but I would like to see something more actionable. For example an issue for each with enough info and clear goal for a community member to start coding straight away... stepharo wrote
Now there is a risk that alain does not deliver so we should - look at what he is doing - we try to document the classes - I'm trying to move some cleans/ideas from bloc to Morphic (introducing Margin, cleaning layoutFrame is a way to improve) - Since bloc runs inside morphic, cleaning morphic reduces the morphic behavior that creeps in Bloc
Here are some ideas to help - for example, if you want to make bloc use Athens transformation - write more tests - write stupid examples
- I'm cleaning menumorph and rewriting a menuMorph for Morphic with the hope that we can blocify the code so that I can propose some simple MenuMorph to Bloc. I'm busy with project proposal writing and other duties but if you want you can join.
- I'm doing the same with theme and basic widgets. - Can we do a simple button in Bloc? - clean the one we have in Morphic
Alain would like to use Athens for the rendering of Bloc elements .... so this is another nice project to help.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Development-Robustness-was-Why-Bloc-tp4774980p47... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi sean Thanks for this mail!!!! About bloc --------- I discussed with alain about this point at ESUG. Alain would like to finish the handlers and a couple of other points, clean everything and release a first version. The problem is that alain is often doing trial and changes. Here is where I think you can help: - turn some of the example for the layouts into tests - start to clean/revisit some basic morphs so that we can turn them into bloc counterparts easily. - I started to look at buttonMorph* - I started to rewrite MenuMorph because it is full of old code. I would like to remove the direct manipulation because it adds a lot of problems. If you want to join let me know. About TxText ------------ - Igor added morphs in text at ESUG and he was revisiting it yesterday. - we should make sure that the configuration is loading in 40 -now mocketry is loading in 40 so the configuration of TxText should be working. - we should check the current use of TextMorph and friends and use TxText Stef On 27/8/14 01:48, Sean P. DeNigris wrote:
The most important items on our IU Experience agenda - Tx and Bloc - are totally reliant on two (brilliant, talented...) programmers while the rest of the community hopes and waits. In no way to I lack appreciation for Alain and Igor's efforts, but this does not seem like a robust or efficient use of our manpower... So, I guess what I'm really asking for both projects is - how can we help?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Development-Robustness-was-Why-Bloc-tp4774980.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
For embedding morphs into text, there's a bit more than i currently did - event handling. Right now, morphs are used to simply render them in-place, and they even not added as a submorphs, therefore no way to deliver any events to them without big troubles. The way how text layout builds (dynamically) poses certain problem on this, since it requires adding/removing submorphs depending whether they visible or not, as well as making sure their position are conform with text layout, and morphic model.. On 27 August 2014 11:28, stepharo <stepharo@free.fr> wrote:
Hi sean
Thanks for this mail!!!!
About bloc --------- I discussed with alain about this point at ESUG. Alain would like to finish the handlers and a couple of other points, clean everything and release a first version. The problem is that alain is often doing trial and changes. Here is where I think you can help:
- turn some of the example for the layouts into tests - start to clean/revisit some basic morphs so that we can turn them into bloc counterparts easily. - I started to look at buttonMorph* - I started to rewrite MenuMorph because it is full of old code. I would like to remove the direct manipulation because it adds a lot of problems. If you want to join let me know.
About TxText ------------ - Igor added morphs in text at ESUG and he was revisiting it yesterday. - we should make sure that the configuration is loading in 40 -now mocketry is loading in 40 so the configuration of TxText should be working. - we should check the current use of TextMorph and friends and use TxText
Stef
On 27/8/14 01:48, Sean P. DeNigris wrote:
The most important items on our IU Experience agenda - Tx and Bloc - are totally reliant on two (brilliant, talented...) programmers while the rest of the community hopes and waits. In no way to I lack appreciation for Alain and Igor's efforts, but this does not seem like a robust or efficient use of our manpower... So, I guess what I'm really asking for both projects is - how can we help?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo- Development-Robustness-was-Why-Bloc-tp4774980.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 27 Aug 2014, at 4:01 , Igor Stasenko <siguctua@gmail.com> wrote:
For embedding morphs into text, there's a bit more than i currently did - event handling. Right now, morphs are used to simply render them in-place, and they even not added as a submorphs, therefore no way to deliver any events to them without big troubles. The way how text layout builds (dynamically) poses certain problem on this, since it requires adding/removing submorphs depending whether they visible or not, as well as making sure their position are conform with text layout, and morphic model..
Are we talking a TextEditor anymore, or are you moving into the domain of a DocumentEditor? Wouldnât it be a better delegation of responsibility to have a text-editor dealing with nothing but text, but also accepting shapes where it is not allowed to render text (and only that), and leave compositing of textEditor and other morphs up to a DocumentEditor. IMHO, if you canât save the contents as an .rtf or something similarly simple, itâs not really a *Text*Editor anymore. Cheers, Henry
Hi sean Thanks for this mail!!!! About bloc --------- I discussed with alain about this point at ESUG. Alain would like to finish the handlers and a couple of other points, clean everything and release a first version. The problem is that alain is often doing trial and changes. Here is where I think you can help: - turn some of the example for the layouts into tests - start to clean/revisit some basic morphs so that we can turn them into bloc counterparts easily. - I started to look at buttonMorph* - I started to rewrite MenuMorph because it is full of old code. I would like to remove the direct manipulation because it adds a lot of problems. If you want to join let me know. About TxText ------------ - Igor added morph - we should make sure that the configuration is loading in 40 -now mocketry is loading in 40 so the configuration of TxText should be working. - we should check the current use of TextMorph and friends and use TxText Stef On 27/8/14 01:48, Sean P. DeNigris wrote:
The most important items on our IU Experience agenda - Tx and Bloc - are totally reliant on two (brilliant, talented...) programmers while the rest of the community hopes and waits. In no way to I lack appreciation for Alain and Igor's efforts, but this does not seem like a robust or efficient use of our manpower... So, I guess what I'm really asking for both projects is - how can we help?
----- Cheers, Sean -- View this message in context:http://forum.world.st/Pharo-Development-Robustness-was-Why-Bloc-tp4774980.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Henrik Johansen -
Igor Stasenko -
Sean P. DeNigris -
stepharo