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 <nicolaihess@web.de> wrote:
2016-02-05 11:33 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:
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. 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