Re: [Pharo-dev] Some questions

[Esteban Lorenzano]

> On 09 Feb 2016, at 13:38, Stéphane Ducasse  wrote:
> 
>> 
>> p.s. To all who see this email: Bloc needs more complains
>> 
>> :)
>> 
>> Some random thoughts:
>> BlWorldElement and BlSpaceElement sounds like this is for elements *in* 
>> space or *in* world, not like
>> *the* WorldElement.
> 
> I agree
> I think that BlWorldEllement should be BlWorld and BlSpaceElement should be 
> BlSpace

in general, using “element” seems to be just as using “object” :P

> 
> 
>> Looking at BlElement definition:
>> 
>> Object subclass: #BlElement
>> uses: TBlPropertiesOwner
>> instanceVariableNames: 'ownerReference visible properties 
>> layoutProperties zIndex spaceReference eventListener errorOnDraw locked 
>> extent shape layoutStrategy children nextElementReference 
>> previousElementReference measuredExtent requestingLayout 
>> oldExtentMeasurementSpec transformation'
>> classVariableNames: ''
>> package: 'Bloc-Core-!Core-Basic'
>> 
>> The properties visible and locked, somehow they don't fit in the structure a 
>> BlElement provides, I don't know why but it looks strange. 
>> zIndex: what defines the order of elements, its zIndex or *are*  they in 
>> different Bloc-Layers and a zIndex would be superfluous?
>> 
>> Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a 
>> BlElement always has and needs, or are they only used during layouting?
>> 
>> children ownerReference nextElementReference previousElementReference, would 
>> it make sense to encapsulate this in one new class, something like a 
>> treeNode/structureNode?
>> 
>> 
>>  
>> 
>> Cheers,
>> Alex
>> 
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr 
> http://www.synectique.eu  / http://www.pharo.org 
>  
> 03 59 35 87 52
> Assistant: Julie Jonas 
> 03 59 57 78 50
> 03 59 35 86 16
> 
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France

Re: [Pharo-dev] Some questions

[Aliaksei Syrel]

>
> The properties visible and locked, somehow they don't fit in the structure
> a BlElement provides, I don't know why but it looks strange.
> zIndex: what defines the order of elements, its zIndex or *are*  they in
> different Bloc-Layers and a zIndex would be superfluous?

Don't worry they are deprecated :) That is why all methods related to
locking/visibility/sticking packaged in *Bloc-Core-*Ugly*.
>From zIndex: setter:

> self flag: 'It should not be just magic number but maybe elevation
>   or z position in pixels or any other material value'.

I was planning to replace it with something stored layout properties.

Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a
> BlElement always has and needs, or are they only used during layouting?

only during layout. They should be moved to layout strategy inst vars.
Thanks for pointing :)

children ownerReference nextElementReference previousElementReference,
> would it make sense to encapsulate this in one new class, something like a
> treeNode/structureNode?

I agree. Don't like so many inst vars in BlElement. They should be somehow
encapsulated in the end. Nice catch!

BlWorldElement and BlSpaceElement sounds like this is for elements *in*
> space or *in* world, not like
> *the* WorldElement.

The same for me... Besides SpaceElement there is BlSpace which is a model.
Doru suggested to rename:

BlWorldElement -> BlWorld
BlSpace -> BlSpaceModel
BlSpaceElement -> BlSpace

Would such naming by more self-describing for you?


Cheers,
Alex

On Tue, Feb 9, 2016 at 12:50 PM, Nicolai Hess  wrote:

>
>
> 2016-02-05 11:33 GMT+01:00 Aliaksei Syrel :
>
>> Nice questions :) I will not able to address all mentioned issues today,
>> but at least will try some. Answers inlined.
>>
>> - What are package-tags starting with !
>>
>> To force Nautilus show most used core packages first in the list. Without
>> "!" they are floating somewhere in the middle of the lists and it takes few
>> microseconds more to find them + eye concentration. Of course before
>> release they will be renamed.
>>
>>  - Why BlLayoutProperties is named like that?
>>> I do not like the ies at the end in particular
>>
>> I wanted to rename to BlLayoutParams. If you like Params then I will
>> rename.
>>
>> - Why UndefinedObject defines vertical?/horizontal?
>>> to me it looks like the auto method generation encountered a nil.
>>
>>  That is to make Bloc compatible with morphic. (
>> https://pharo.fogbugz.com/f/cases/17502) LayoutProperties of Morph can
>> be nil. So I decided to add extension methods to nil instead of making
>> architecture of Bloc ugly :) Don't see any better solution.
>>
>> - I cannot close the debugger because I get a DNU askOkToClose
>>
>> I too. I also can't close Implementors/Senders browser for the same
>> reason. No idea why.
>>
>>  - Why BlMargin is not polymorphic with Margin?
>>
>> Please, don't take next sentence as joke, but I think it is Margin that
>> is not polymorphic with BlMargin...
>> In Bloc we have padding and margin. They both modify bounds. I don't like
>> to use existing Margin class to describe padding.. Still BlMargin has
>> similar, not identical api as Margin.
>> Also check Margin's api.. It has #rightBottom method - which is the only
>> one to return Point. Where is leftBottom or rightTop? wat.
>>
>>
>>
>>> - what is BlPaint and what are its collaborators.
>>
>> is used for filling and stroking shapes.
>> Milestone is Bloc-beta.
>>
>> - What is a coordinateHolder? Why don’t we use a point?
>>
>> Kind of helper. It is used in events and event listeners. I still didn't
>> invest time in revising events..
>>
>>  - Events needs some class comments:
>>> - API?
>>> -
>>
>> Milestone is Bloc-beta.
>>
>> - Why do we have brickValue: in BlAnimation? to me it looks like a layer
>>> violation.
>>
>> yes. BlAnimation should be deleted.
>>
>> - in BlPath: I have no diea what is a sparta shapes :)
>>> I got confused by
>>> "I'm responsible for building shape path on passed athens path builder.”
>>
>> Well, yes :)
>>
>> Oops the vm crashed :)
>>
>> Oho! It took so long to crash! =^.^=
>>
>> p.s. To all who see this email: Bloc needs more complains
>>
>
> :)
>
> Some random thoughts:
> BlWorldElement and BlSpaceElement sounds like this is for elements *in*
> space or *in* world, not like
> *the* WorldElement.
>
> Looking at BlElement definition:
>
> Object subclass: #BlElement
> uses: TBlPropertiesOwner
> instanceVariableNames: 'ownerReference visible properties
> layoutProperties zIndex spaceReference eventListener errorOnDraw locked
> extent shape layoutStrategy children nextElementReference
> previousElementReference measuredExtent requestingLayout
> oldExtentMeasurementSpec transformation'
> classVariableNames: ''
> package: 'Bloc-Core-!Core-Basic'
>
> The properties visible and locked, somehow they don't fit in the structure
> a BlElement provides, I don't know why but it looks strange.
> 

Re: [Pharo-dev] Some questions

[Alain Plantec via Pharo-dev]

--- Begin Message ---
> 
> The same for me... Besides SpaceElement there is BlSpace which is a model.
> Doru suggested to rename:
> 
> BlWorldElement -> BlWorld
> BlSpace -> BlSpaceModel
> BlSpaceElement -> BlSpace
> 
> Would such naming by more self-describing for you?

yes
Alain



--- End Message ---

Re: [Pharo-dev] some questions about bloc

[stepharo]

Are you interested in some feedback for brick, or is it in a too early 
stage?


please.

2015-08-10 12:36 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com 
mailto:alex.sy...@gmail.com:


Hi Nicolai,

Thanks for looking into this :) Hierarchy will be optimised.
Basically EnclosedView will gone - ProtoView will be a
composition, this will remove code duplication and simplify
addition of new functionality. After that rounded rectangle and
rectangle will be merged. So in the end hierarchy will be
BlProtoView - BlView - BlRectangle - BrStringView -
BrButtonView which is simple enough.

As Stephan said theme just provides default values and also skin
for morph. Skin provides view and different styles for states like
hovered, pressed, active, focused, disabled and others.

Summarizing, with event listener any arbitrary morph can get
dynamic behaviour on events, with skins any arbitrary morph can be
deeply styled.

Maybe it makes sense to move theme from BlProtoView to BlMorph.

Cheers,
Alex

On Aug 9, 2015 9:57 PM, Nicolai Hess nicolaih...@web.de
mailto:nicolaih...@web.de wrote:



2015-08-09 20:17 GMT+02:00 Aliaksei Syrel
alex.sy...@gmail.com mailto:alex.sy...@gmail.com:

Hi

Thanks for your response.

Animation was copied from other project and has nothing to
do with Bloc. However, it is still there for a moment.
BTW, example on the class side is still morphic.


Yes, but  it only works in a bloc world

Yes, it does not make any sense to theme CircleView and
ImageView, but it makes sense to theme their subclasses,
like BrButtonView. Theming mechanism is not integrated in
Bloc for now.


But why dont we put this into a BlThemeableView ?
All subclasses of BlProtoView that want to support color or
fillstyles, now have a theme property too.
Why do they need a color property if the color is theme-dependent.

Btw. what is that strange hierarchy for BrButtonView:
BlProtoView - BlView - BlEnclosedView - BlRectangleView -
BlRoundedRectangleView - BrRectangleView - BrStringView -
BrButtonView
A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

I think I don't understand bloc


Cheers,
Alex

On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de
mailto:nicolaih...@web.de wrote:

BlAlarmQueue
- split into two classes?
  Queue : managing the add/remove/sort
  Scheduler : process the Alarms
- alarm/alarmqueue both accessing and check the time
Time now
  I would put both checks to, either  the alarm OR the
queue/scheduler.
  And don't use Time now explicit, if we put this
behind a method call, we
can easily create alarm queue mocs for unit tests.
- readding periodic alarms: shouldn't this be done by
the alarm itself -  the queue should not care, whether
a alarm is periodic.

Some alarm examples put the queue into the morphs
property dictionary. I could find out why
this is necessary.


Layout:
Box/Column/Row Layout and corresponding cells define a
double linked list, we already
have a DoubleLinkedList, can we use the
DoubleLinkedList instead of reimplmenting this
on the layout/cells?

Tablelayout: is this work in progress or abandoned?
Currently it shares much code with
the BoxLayout, but it does not look like it is working.

Theming:
#theme is a property of BlProtoView - isn't this to
low level for defining theming support?
How would you theme a CircleView or an ImageView?


Animation:
what are all these Logics?
animationLogic
toLogic
stepLogic and steppedLogic(!?)
ifLogic 

Is this a software pattern ? I have never seen this
before.
(For example we use sortBlock but not sortLogic).
How about ValueHolder or good old Block.

And ifLogic sounds like a condition, why don't we
name it. ... condition?
And putting all this logic into one animation class
scares me.


About the class comment syntax:
- is this pillar syntax? I think this is difficult to
read. Do you use that syntax, because we
want to use a pillar as comment text and 

Re: [Pharo-dev] some questions about bloc

[Aliaksei Syrel]

Yes, shoot :)

On Sun, Aug 16, 2015 at 10:54 AM, stepharo steph...@free.fr wrote:




 Are you interested in some feedback for brick, or is it in a too early
 stage?


 please.


 2015-08-10 12:36 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi Nicolai,

 Thanks for looking into this :) Hierarchy will be optimised. Basically
 EnclosedView will gone - ProtoView will be a composition, this will remove
 code duplication and simplify addition of new functionality. After that
 rounded rectangle and rectangle will be merged. So in the end hierarchy
 will be BlProtoView - BlView - BlRectangle - BrStringView -
 BrButtonView which is simple enough.

 As Stephan said theme just provides default values and also skin for
 morph. Skin provides view and different styles for states like hovered,
 pressed, active, focused, disabled and others.

 Summarizing, with event listener any arbitrary morph can get dynamic
 behaviour on events, with skins any arbitrary morph can be deeply styled.

 Maybe it makes sense to move theme from BlProtoView to BlMorph.

 Cheers,
 Alex
 On Aug 9, 2015 9:57 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi

 Thanks for your response.


 Animation was copied from other project and has nothing to do with
 Bloc. However, it is still there for a moment. BTW, example on the class
 side is still morphic.


 Yes, but  it only works in a bloc world


 Yes, it does not make any sense to theme CircleView and ImageView, but
 it makes sense to theme their subclasses, like BrButtonView. Theming
 mechanism is not integrated in Bloc for now.


 But why dont we put this into a BlThemeableView ?
 All subclasses of BlProtoView that want to support color or fillstyles,
 now have a theme property too.
 Why do they need a color property if the color is theme-dependent.

 Btw. what is that strange hierarchy for BrButtonView:
 BlProtoView - BlView - BlEnclosedView - BlRectangleView -
 BlRoundedRectangleView - BrRectangleView - BrStringView - BrButtonView
 A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

 I think I don't understand bloc


 Cheers,
 Alex
 On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method
 call, we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself
 -  the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary.
 I could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked
 list, we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it
 shares much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for
 defining theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ...
 condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or
 is it to share comments between class comments and the bloc doc book,
 easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[Andrei Chis]

Feedback is always welcomed :)
Still in the brick repo there are, at the moment, quite some
sub-projects/experiments.
We are working now on making a better description for what is already in a
more advanced state.
For example the logic for skin, styes and theme modules is in a good state.

Cheers,
Andrei

On Sat, Aug 15, 2015 at 11:59 PM, Nicolai Hess nicolaih...@web.de wrote:

 Are you interested in some feedback for brick, or is it in a too early
 stage?

 2015-08-10 12:36 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi Nicolai,

 Thanks for looking into this :) Hierarchy will be optimised. Basically
 EnclosedView will gone - ProtoView will be a composition, this will remove
 code duplication and simplify addition of new functionality. After that
 rounded rectangle and rectangle will be merged. So in the end hierarchy
 will be BlProtoView - BlView - BlRectangle - BrStringView -
 BrButtonView which is simple enough.

 As Stephan said theme just provides default values and also skin for
 morph. Skin provides view and different styles for states like hovered,
 pressed, active, focused, disabled and others.

 Summarizing, with event listener any arbitrary morph can get dynamic
 behaviour on events, with skins any arbitrary morph can be deeply styled.

 Maybe it makes sense to move theme from BlProtoView to BlMorph.

 Cheers,
 Alex
 On Aug 9, 2015 9:57 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi

 Thanks for your response.


 Animation was copied from other project and has nothing to do with
 Bloc. However, it is still there for a moment. BTW, example on the class
 side is still morphic.


 Yes, but  it only works in a bloc world


 Yes, it does not make any sense to theme CircleView and ImageView, but
 it makes sense to theme their subclasses, like BrButtonView. Theming
 mechanism is not integrated in Bloc for now.


 But why dont we put this into a BlThemeableView ?
 All subclasses of BlProtoView that want to support color or fillstyles,
 now have a theme property too.
 Why do they need a color property if the color is theme-dependent.

 Btw. what is that strange hierarchy for BrButtonView:
 BlProtoView - BlView - BlEnclosedView - BlRectangleView -
 BlRoundedRectangleView - BrRectangleView - BrStringView - BrButtonView
 A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

 I think I don't understand bloc


 Cheers,
 Alex
 On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method
 call, we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself
 -  the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary.
 I could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked
 list, we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it
 shares much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for
 defining theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ...
 condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or
 is it to share comments between class comments and the bloc doc book,
 easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[Nicolai Hess]

Are you interested in some feedback for brick, or is it in a too early
stage?

2015-08-10 12:36 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi Nicolai,

 Thanks for looking into this :) Hierarchy will be optimised. Basically
 EnclosedView will gone - ProtoView will be a composition, this will remove
 code duplication and simplify addition of new functionality. After that
 rounded rectangle and rectangle will be merged. So in the end hierarchy
 will be BlProtoView - BlView - BlRectangle - BrStringView -
 BrButtonView which is simple enough.

 As Stephan said theme just provides default values and also skin for
 morph. Skin provides view and different styles for states like hovered,
 pressed, active, focused, disabled and others.

 Summarizing, with event listener any arbitrary morph can get dynamic
 behaviour on events, with skins any arbitrary morph can be deeply styled.

 Maybe it makes sense to move theme from BlProtoView to BlMorph.

 Cheers,
 Alex
 On Aug 9, 2015 9:57 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi

 Thanks for your response.


 Animation was copied from other project and has nothing to do with Bloc.
 However, it is still there for a moment. BTW, example on the class side is
 still morphic.


 Yes, but  it only works in a bloc world


 Yes, it does not make any sense to theme CircleView and ImageView, but
 it makes sense to theme their subclasses, like BrButtonView. Theming
 mechanism is not integrated in Bloc for now.


 But why dont we put this into a BlThemeableView ?
 All subclasses of BlProtoView that want to support color or fillstyles,
 now have a theme property too.
 Why do they need a color property if the color is theme-dependent.

 Btw. what is that strange hierarchy for BrButtonView:
 BlProtoView - BlView - BlEnclosedView - BlRectangleView -
 BlRoundedRectangleView - BrRectangleView - BrStringView - BrButtonView
 A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

 I think I don't understand bloc


 Cheers,
 Alex
 On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method
 call, we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself
 -  the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary.
 I could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked
 list, we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it
 shares much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for
 defining theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ...
 condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or
 is it to share comments between class comments and the bloc doc book,
 easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[stepharo]

Thanks nicolai for all these questions.

Writing more tests is cool. I started and each time alain imporved Bloc :)
Alain is driving somwhere in vacation with nearly no internet.

Stef


BlAlarmQueue
- split into two classes?
  Queue : managing the add/remove/sort
  Scheduler : process the Alarms
- alarm/alarmqueue both accessing and check the time Time now
  I would put both checks to, either  the alarm OR the queue/scheduler.
  And don't use Time now explicit, if we put this behind a method 
call, we

can easily create alarm queue mocs for unit tests.
- readding periodic alarms: shouldn't this be done by the alarm itself 
-  the queue should not care, whether a alarm is periodic.


Some alarm examples put the queue into the morphs property dictionary. 
I could find out why

this is necessary.


Layout:
Box/Column/Row Layout and corresponding cells define a double linked 
list, we already
have a DoubleLinkedList, can we use the DoubleLinkedList instead of 
reimplmenting this

on the layout/cells?

Yes.

Tablelayout: is this work in progress or abandoned? Currently it 
shares much code with

the BoxLayout, but it does not look like it is working.


I think that this is more a work in progress.


Theming:
#theme is a property of BlProtoView - isn't this to low level for 
defining theming support?

How would you theme a CircleView or an ImageView?


Animation:
what are all these Logics?
animationLogic
toLogic
stepLogic and steppedLogic(!?)
ifLogic 

I would really like to see if Viva animation could be used in Bloc.
StephaneDucasse / PetitsBazars
 viva

Alex used it for Roassal and this is nice but we need more experience 
and to check if it is compatible with the design of bloc.




Is this a software pattern ? I have never seen this before.

(For example we use sortBlock but not sortLogic).
How about ValueHolder or good old Block.

And ifLogic sounds like a condition, why don't we name it. ... 
condition?

And putting all this logic into one animation class scares me.


About the class comment syntax:
- is this pillar syntax? I think this is difficult to read. Do you use 
that syntax, because we
want to use a pillar as comment text and build a renderer for this or 
is it to share comments between class comments and the bloc doc book, 
easily?

yes.

I can help with documenting the classes but I find it difficult to see 
which parts of bloc
are just tests/proof of concept or are supposed to be in the final 
version. Maybe I miss the big picture?


What I can tell is that I tried several times and bloc changed at that 
time :)
Now it is ***much*** more stable so this is the time to push. Did you 
read a bit the documentation we started on BlocCore?

So having tests would be nice.

I was planning to start to port some little classes I have around the 
game such as ledMorph and other to see how it goes.



Stef

Re: [Pharo-dev] some questions about bloc

[Aliaksei Syrel]

Hi Nicolai,

Thanks for looking into this :) Hierarchy will be optimised. Basically
EnclosedView will gone - ProtoView will be a composition, this will remove
code duplication and simplify addition of new functionality. After that
rounded rectangle and rectangle will be merged. So in the end hierarchy
will be BlProtoView - BlView - BlRectangle - BrStringView -
BrButtonView which is simple enough.

As Stephan said theme just provides default values and also skin for morph.
Skin provides view and different styles for states like hovered, pressed,
active, focused, disabled and others.

Summarizing, with event listener any arbitrary morph can get dynamic
behaviour on events, with skins any arbitrary morph can be deeply styled.

Maybe it makes sense to move theme from BlProtoView to BlMorph.

Cheers,
Alex
On Aug 9, 2015 9:57 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi

 Thanks for your response.


 Animation was copied from other project and has nothing to do with Bloc.
 However, it is still there for a moment. BTW, example on the class side is
 still morphic.


 Yes, but  it only works in a bloc world


 Yes, it does not make any sense to theme CircleView and ImageView, but it
 makes sense to theme their subclasses, like BrButtonView. Theming mechanism
 is not integrated in Bloc for now.


 But why dont we put this into a BlThemeableView ?
 All subclasses of BlProtoView that want to support color or fillstyles,
 now have a theme property too.
 Why do they need a color property if the color is theme-dependent.

 Btw. what is that strange hierarchy for BrButtonView:
 BlProtoView - BlView - BlEnclosedView - BlRectangleView -
 BlRoundedRectangleView - BrRectangleView - BrStringView - BrButtonView
 A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

 I think I don't understand bloc


 Cheers,
 Alex
 On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method
 call, we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself
 -  the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary. I
 could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked
 list, we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it
 shares much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for
 defining theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ...
 condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or is
 it to share comments between class comments and the bloc doc book, easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[Nicolai Hess]

2015-08-10 12:36 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi Nicolai,

 Thanks for looking into this :) Hierarchy will be optimised. Basically
 EnclosedView will gone - ProtoView will be a composition, this will remove
 code duplication and simplify addition of new functionality. After that
 rounded rectangle and rectangle will be merged. So in the end hierarchy
 will be BlProtoView - BlView - BlRectangle - BrStringView -
 BrButtonView which is simple enough.

merging EnclosedView and ProtoView:
+1



 As Stephan said theme just provides default values and also skin for
 morph.

Ok, yes that makes sense.

 Skin provides view and different styles for states like hovered, pressed,
 active, focused, disabled and others.

Summarizing, with event listener any arbitrary morph can get dynamic
 behaviour on events, with skins any arbitrary morph can be deeply styled.

 Maybe it makes sense to move theme from BlProtoView to BlMorph.

 Cheers,
 Alex
 On Aug 9, 2015 9:57 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-08-09 20:17 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi

 Thanks for your response.


 Animation was copied from other project and has nothing to do with Bloc.
 However, it is still there for a moment. BTW, example on the class side is
 still morphic.


 Yes, but  it only works in a bloc world


 Yes, it does not make any sense to theme CircleView and ImageView, but
 it makes sense to theme their subclasses, like BrButtonView. Theming
 mechanism is not integrated in Bloc for now.


 But why dont we put this into a BlThemeableView ?
 All subclasses of BlProtoView that want to support color or fillstyles,
 now have a theme property too.
 Why do they need a color property if the color is theme-dependent.

 Btw. what is that strange hierarchy for BrButtonView:
 BlProtoView - BlView - BlEnclosedView - BlRectangleView -
 BlRoundedRectangleView - BrRectangleView - BrStringView - BrButtonView
 A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

 I think I don't understand bloc


 Cheers,
 Alex
 On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method
 call, we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself
 -  the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary.
 I could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked
 list, we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it
 shares much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for
 defining theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ...
 condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or
 is it to share comments between class comments and the bloc doc book,
 easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[Aliaksei Syrel]

Hi

Animation was copied from other project and has nothing to do with Bloc.
However, it is still there for a moment. BTW, example on the class side is
still morphic.

Yes, it does not make any sense to theme CircleView and ImageView, but it
makes sense to theme their subclasses, like BrButtonView. Theming mechanism
is not integrated in Bloc for now.

Cheers,
Alex
On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method call,
 we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself -
 the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary. I
 could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked list,
 we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it shares
 much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for defining
 theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ... condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or is
 it to share comments between class comments and the bloc doc book, easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[Nicolai Hess]

2015-08-09 20:17 GMT+02:00 Aliaksei Syrel alex.sy...@gmail.com:

 Hi

Thanks for your response.


 Animation was copied from other project and has nothing to do with Bloc.
 However, it is still there for a moment. BTW, example on the class side is
 still morphic.


Yes, but  it only works in a bloc world


 Yes, it does not make any sense to theme CircleView and ImageView, but it
 makes sense to theme their subclasses, like BrButtonView. Theming mechanism
 is not integrated in Bloc for now.


But why dont we put this into a BlThemeableView ?
All subclasses of BlProtoView that want to support color or fillstyles, now
have a theme property too.
Why do they need a color property if the color is theme-dependent.

Btw. what is that strange hierarchy for BrButtonView:
BlProtoView - BlView - BlEnclosedView - BlRectangleView -
BlRoundedRectangleView - BrRectangleView - BrStringView - BrButtonView
A BlRectangleView, a RoundedRectangleView and a BrRectangleView?

I think I don't understand bloc


Cheers,
 Alex
 On Aug 9, 2015 7:29 PM, Nicolai Hess nicolaih...@web.de wrote:

 BlAlarmQueue
 - split into two classes?
   Queue : managing the add/remove/sort
   Scheduler : process the Alarms
 - alarm/alarmqueue both accessing and check the time Time now
   I would put both checks to, either  the alarm OR the queue/scheduler.
   And don't use Time now explicit, if we put this behind a method call,
 we
 can easily create alarm queue mocs for unit tests.
 - readding periodic alarms: shouldn't this be done by the alarm itself -
 the queue should not care, whether a alarm is periodic.

 Some alarm examples put the queue into the morphs property dictionary. I
 could find out why
 this is necessary.


 Layout:
 Box/Column/Row Layout and corresponding cells define a double linked
 list, we already
 have a DoubleLinkedList, can we use the DoubleLinkedList instead of
 reimplmenting this
 on the layout/cells?

 Tablelayout: is this work in progress or abandoned? Currently it shares
 much code with
 the BoxLayout, but it does not look like it is working.

 Theming:
 #theme is a property of BlProtoView - isn't this to low level for
 defining theming support?
 How would you theme a CircleView or an ImageView?


 Animation:
 what are all these Logics?
 animationLogic
 toLogic
 stepLogic and steppedLogic(!?)
 ifLogic 

 Is this a software pattern ? I have never seen this before.
 (For example we use sortBlock but not sortLogic).
 How about ValueHolder or good old Block.

 And ifLogic sounds like a condition, why don't we name it. ...
 condition?
 And putting all this logic into one animation class scares me.


 About the class comment syntax:
 - is this pillar syntax? I think this is difficult to read. Do you use
 that syntax, because we
 want to use a pillar as comment text and build a renderer for this or is
 it to share comments between class comments and the bloc doc book, easily?

 I can help with documenting the classes but I find it difficult to see
 which parts of bloc
 are just tests/proof of concept or are supposed to be in the final
 version. Maybe I miss the big picture?


 nicolai

Re: [Pharo-dev] some questions about bloc

[Stephan Eggermont]

On 09/08/15 21:57, Nicolai Hess wrote:

But why dont we put this into a BlThemeableView ?
All subclasses of BlProtoView that want to support color or fillstyles,
now have a theme property too.
Why do they need a color property if the color is theme-dependent.


Because the theme only provides default values (and reset to theme).

Stephan

Re: [Pharo-dev] some questions about current GToolkit issues

[Nicolai Hess]

2015-07-04 7:58 GMT+02:00 Tudor Girba tu...@tudorgirba.com:

 Hi,

 When I said that the goal for the new inspector is Pharo 6, I meant Pharo
 5 - at least as an alternative to the existing one.

 Cheers,
 Doru


 On Sat, Jul 4, 2015 at 7:31 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi Nicolai,

 Please

 On Fri, Jul 3, 2015 at 10:53 PM, Nicolai Hess nicolaih...@web.de wrote:

 15102 https://pharo.fogbugz.com/default.asp?15102
 lost worldmenu
 Is anyone working on this, it is quite annoying, happens to me a couple
 of time - per day.
 Everytime I restart the image to get the menu back. Is there any other
 way to
 recreate the worldmenu?


 No, because we do not know how to reproduce it (like the message says).
 If anyone knows how, this would help.



 15772 https://pharo.fogbugz.com/default.asp?15772
 spotter is undebuggable
 Andrei said on the ML he knows what the problem is. Are you working on
 this?
 This makes it difficult to work/analyse other spotter bugs.


 I just added a note in the issue. Please provide a step-by-step situation.



 14569 https://pharo.fogbugz.com/default.asp?14569
 GTInspector should do live updates of objects and their slots
 This was considered a really important issue. Who works on this, any
 progress?


 We have a solution in the image, but it is not scalable (the rendering
 was just too slow), so it is disabled by default (custom presentations can
 use it if they want).

 We are working on this in two ways:
 - a new version of the inspector based on bloc and without glamour. This
 will take a while to finish, but the goal is to make it until Pharo 6.
 - as soon as we can hook on object-specific events we will use that
 mechanism to identify the need for an update



 There are some issues tagged for pharo 40. Who will take care of it?
 Backport the
 fixes or change the milestone


 As far as I am concerned, we should keep the backporting to critical
 cases only. Right now, I see none of them as being critical.



 There are some more issues (for example about the
 displayString/printString) waiting for
 some feedback and comments.


 Ok. We will try to go over them.


 I wasn't happy with the way spotter  co were pushed into the 4.0 release.
 To many changes and new features even during code freeze. I do understand
 that it was important to have this in the release to get feedback.
 But now I wish more support, we already have too many loose ends,
 unfinished projects
 and to few people working on them.


 I do not see the relation between adding spotter and the support.


 Please help, and keep up working on this or give some feedback or comment
 the
 open issues.


 This is an unfortunate period simply because it is holidays time and
 there are other things that prevented us to work on it.

 Cheers,
 Doru





can you please check this issues, and comment if you plan to work on it.


14247 https://pharo.fogbugz.com/default.asp?14247
inspector on nil


14584 https://pharo.fogbugz.com/default.asp?14584
GTInspector: explore only


14994 https://pharo.fogbugz.com/default.asp?14994
GTInspector is slow for large strings


If not, I 'll close it as wontfix.





 nicolai




 --
 www.tudorgirba.com

 Every thing has its own flow




 --
 www.tudorgirba.com

 Every thing has its own flow

Re: [Pharo-dev] some questions about current GToolkit issues

[Tudor Girba]

Thanks for pinging me and for the patience. I commented on all these issues.

Cheers,
Doru

On Mon, Jul 6, 2015 at 7:08 PM, Nicolai Hess nicolaih...@web.de wrote:



 2015-07-04 7:58 GMT+02:00 Tudor Girba tu...@tudorgirba.com:

 Hi,

 When I said that the goal for the new inspector is Pharo 6, I meant Pharo
 5 - at least as an alternative to the existing one.

 Cheers,
 Doru


 On Sat, Jul 4, 2015 at 7:31 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi Nicolai,

 Please

 On Fri, Jul 3, 2015 at 10:53 PM, Nicolai Hess nicolaih...@web.de
 wrote:

 15102 https://pharo.fogbugz.com/default.asp?15102
 lost worldmenu
 Is anyone working on this, it is quite annoying, happens to me a couple
 of time - per day.
 Everytime I restart the image to get the menu back. Is there any other
 way to
 recreate the worldmenu?


 No, because we do not know how to reproduce it (like the message says).
 If anyone knows how, this would help.



 15772 https://pharo.fogbugz.com/default.asp?15772
 spotter is undebuggable
 Andrei said on the ML he knows what the problem is. Are you working on
 this?
 This makes it difficult to work/analyse other spotter bugs.


 I just added a note in the issue. Please provide a step-by-step
 situation.



 14569 https://pharo.fogbugz.com/default.asp?14569
 GTInspector should do live updates of objects and their slots
 This was considered a really important issue. Who works on this, any
 progress?


 We have a solution in the image, but it is not scalable (the rendering
 was just too slow), so it is disabled by default (custom presentations can
 use it if they want).

 We are working on this in two ways:
 - a new version of the inspector based on bloc and without glamour. This
 will take a while to finish, but the goal is to make it until Pharo 6.
 - as soon as we can hook on object-specific events we will use that
 mechanism to identify the need for an update



 There are some issues tagged for pharo 40. Who will take care of it?
 Backport the
 fixes or change the milestone


 As far as I am concerned, we should keep the backporting to critical
 cases only. Right now, I see none of them as being critical.



 There are some more issues (for example about the
 displayString/printString) waiting for
 some feedback and comments.


 Ok. We will try to go over them.


 I wasn't happy with the way spotter  co were pushed into the 4.0
 release.
 To many changes and new features even during code freeze. I do
 understand
 that it was important to have this in the release to get feedback.
 But now I wish more support, we already have too many loose ends,
 unfinished projects
 and to few people working on them.


 I do not see the relation between adding spotter and the support.


 Please help, and keep up working on this or give some feedback or
 comment the
 open issues.


 This is an unfortunate period simply because it is holidays time and
 there are other things that prevented us to work on it.

 Cheers,
 Doru





 can you please check this issues, and comment if you plan to work on it.


 14247 https://pharo.fogbugz.com/default.asp?14247
 inspector on nil


 14584 https://pharo.fogbugz.com/default.asp?14584
 GTInspector: explore only


 14994 https://pharo.fogbugz.com/default.asp?14994
 GTInspector is slow for large strings


 If not, I 'll close it as wontfix.





 nicolai




 --
 www.tudorgirba.com

 Every thing has its own flow




 --
 www.tudorgirba.com

 Every thing has its own flow





-- 
www.tudorgirba.com

Every thing has its own flow

Re: [Pharo-dev] some questions about current GToolkit issues

[Nicolai Hess]

Thank you Doru

2015-07-04 7:31 GMT+02:00 Tudor Girba tu...@tudorgirba.com:

 Hi Nicolai,

 Please

 On Fri, Jul 3, 2015 at 10:53 PM, Nicolai Hess nicolaih...@web.de wrote:

 15102 https://pharo.fogbugz.com/default.asp?15102
 lost worldmenu
 Is anyone working on this, it is quite annoying, happens to me a couple
 of time - per day.
 Everytime I restart the image to get the menu back. Is there any other
 way to
 recreate the worldmenu?


 No, because we do not know how to reproduce it (like the message says). If
 anyone knows how, this would help.



 15772 https://pharo.fogbugz.com/default.asp?15772
 spotter is undebuggable
 Andrei said on the ML he knows what the problem is. Are you working on
 this?
 This makes it difficult to work/analyse other spotter bugs.


 I just added a note in the issue. Please provide a step-by-step situation.


thanks,
done





 14569 https://pharo.fogbugz.com/default.asp?14569
 GTInspector should do live updates of objects and their slots
 This was considered a really important issue. Who works on this, any
 progress?


 We have a solution in the image, but it is not scalable (the rendering was
 just too slow), so it is disabled by default (custom presentations can use
 it if they want).


I know, I can read the bug tracker comments, the question was if this is
going to be solved for the current release - apparently not.



 We are working on this in two ways:
 - a new version of the inspector based on bloc and without glamour. This
 will take a while to finish, but the goal is to make it until Pharo 6.
 - as soon as we can hook on object-specific events we will use that
 mechanism to identify the need for an update


Ok, I see, you alread commented the bug report, thanks!





 There are some issues tagged for pharo 40. Who will take care of it?
 Backport the
 fixes or change the milestone


 As far as I am concerned, we should keep the backporting to critical cases
 only. Right now, I see none of them as being critical.


can you add a note to that issues, or move the milestone, please





 There are some more issues (for example about the
 displayString/printString) waiting for
 some feedback and comments.


 Ok. We will try to go over them.


 I wasn't happy with the way spotter  co were pushed into the 4.0 release.
 To many changes and new features even during code freeze. I do understand
 that it was important to have this in the release to get feedback.
 But now I wish more support, we already have too many loose ends,
 unfinished projects
 and to few people working on them.


 I do not see the relation between adding spotter and the support.


I meant some help, feedback on the open issues,anything that shows who is
working on what.
At the moment it looks as if the work had stopped. Some changes (like
settings/menu morph preview)
were added during the code freeze. But they don't work in the release. I
filed a bug report and asked
multiple times - no feedback. Looks like no one cares. The same for a
couple of other issues.




 Please help, and keep up working on this or give some feedback or comment
 the
 open issues.


 This is an unfortunate period simply because it is holidays time and there
 are other things that prevented us to work on it.


holidays are ok :) this is the reason I waited so long before asking for
help, but now, after two months of no progress, I just wanted to know.



 Cheers,
 Doru



 nicolai




 --
 www.tudorgirba.com

 Every thing has its own flow

Re: [Pharo-dev] some questions about current GToolkit issues

[Tudor Girba]

Hi Nicolai,

Please

On Fri, Jul 3, 2015 at 10:53 PM, Nicolai Hess nicolaih...@web.de wrote:

 15102 https://pharo.fogbugz.com/default.asp?15102
 lost worldmenu
 Is anyone working on this, it is quite annoying, happens to me a couple of
 time - per day.
 Everytime I restart the image to get the menu back. Is there any other way
 to
 recreate the worldmenu?


No, because we do not know how to reproduce it (like the message says). If
anyone knows how, this would help.



 15772 https://pharo.fogbugz.com/default.asp?15772
 spotter is undebuggable
 Andrei said on the ML he knows what the problem is. Are you working on
 this?
 This makes it difficult to work/analyse other spotter bugs.


I just added a note in the issue. Please provide a step-by-step situation.



 14569 https://pharo.fogbugz.com/default.asp?14569
 GTInspector should do live updates of objects and their slots
 This was considered a really important issue. Who works on this, any
 progress?


We have a solution in the image, but it is not scalable (the rendering was
just too slow), so it is disabled by default (custom presentations can use
it if they want).

We are working on this in two ways:
- a new version of the inspector based on bloc and without glamour. This
will take a while to finish, but the goal is to make it until Pharo 6.
- as soon as we can hook on object-specific events we will use that
mechanism to identify the need for an update



 There are some issues tagged for pharo 40. Who will take care of it?
 Backport the
 fixes or change the milestone


As far as I am concerned, we should keep the backporting to critical cases
only. Right now, I see none of them as being critical.



 There are some more issues (for example about the
 displayString/printString) waiting for
 some feedback and comments.


Ok. We will try to go over them.


I wasn't happy with the way spotter  co were pushed into the 4.0 release.
 To many changes and new features even during code freeze. I do understand
 that it was important to have this in the release to get feedback.
 But now I wish more support, we already have too many loose ends,
 unfinished projects
 and to few people working on them.


I do not see the relation between adding spotter and the support.


Please help, and keep up working on this or give some feedback or comment
 the
 open issues.


This is an unfortunate period simply because it is holidays time and there
are other things that prevented us to work on it.

Cheers,
Doru



 nicolai




-- 
www.tudorgirba.com

Every thing has its own flow

Re: [Pharo-dev] some questions about current GToolkit issues

[Tudor Girba]

Hi,

When I said that the goal for the new inspector is Pharo 6, I meant Pharo 5
- at least as an alternative to the existing one.

Cheers,
Doru


On Sat, Jul 4, 2015 at 7:31 AM, Tudor Girba tu...@tudorgirba.com wrote:

 Hi Nicolai,

 Please

 On Fri, Jul 3, 2015 at 10:53 PM, Nicolai Hess nicolaih...@web.de wrote:

 15102 https://pharo.fogbugz.com/default.asp?15102
 lost worldmenu
 Is anyone working on this, it is quite annoying, happens to me a couple
 of time - per day.
 Everytime I restart the image to get the menu back. Is there any other
 way to
 recreate the worldmenu?


 No, because we do not know how to reproduce it (like the message says). If
 anyone knows how, this would help.



 15772 https://pharo.fogbugz.com/default.asp?15772
 spotter is undebuggable
 Andrei said on the ML he knows what the problem is. Are you working on
 this?
 This makes it difficult to work/analyse other spotter bugs.


 I just added a note in the issue. Please provide a step-by-step situation.



 14569 https://pharo.fogbugz.com/default.asp?14569
 GTInspector should do live updates of objects and their slots
 This was considered a really important issue. Who works on this, any
 progress?


 We have a solution in the image, but it is not scalable (the rendering was
 just too slow), so it is disabled by default (custom presentations can use
 it if they want).

 We are working on this in two ways:
 - a new version of the inspector based on bloc and without glamour. This
 will take a while to finish, but the goal is to make it until Pharo 6.
 - as soon as we can hook on object-specific events we will use that
 mechanism to identify the need for an update



 There are some issues tagged for pharo 40. Who will take care of it?
 Backport the
 fixes or change the milestone


 As far as I am concerned, we should keep the backporting to critical cases
 only. Right now, I see none of them as being critical.



 There are some more issues (for example about the
 displayString/printString) waiting for
 some feedback and comments.


 Ok. We will try to go over them.


 I wasn't happy with the way spotter  co were pushed into the 4.0 release.
 To many changes and new features even during code freeze. I do understand
 that it was important to have this in the release to get feedback.
 But now I wish more support, we already have too many loose ends,
 unfinished projects
 and to few people working on them.


 I do not see the relation between adding spotter and the support.


 Please help, and keep up working on this or give some feedback or comment
 the
 open issues.


 This is an unfortunate period simply because it is holidays time and there
 are other things that prevented us to work on it.

 Cheers,
 Doru



 nicolai




 --
 www.tudorgirba.com

 Every thing has its own flow




-- 
www.tudorgirba.com

Every thing has its own flow

Re: [Pharo-dev] some questions about Object and Spec

[Esteban A. Maringolo]

So it seems you don't follow your doctor advice.

:)
Esteban A. Maringolo


2014/1/6 Stéphane Ducasse stephane.duca...@inria.fr:
 Hi ben

 I was looking at Spec code and I wonder why we have these methods in Object?

 asWidget

 ^ self

 I do not get why any object could get a widget.

 isSpecAdapter

 ^ false

 since an adapter is a subclass of Morph why can we move it to morph?
 If in the future we have other adapter then we will just add isSpecAdapter to 
 the root of the new hierarchy.

 isSpecLayout

 ^ false

 For this one I did not have an idea.

 Stef