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