On 3 April 2016 at 23:41, Igor Stasenko <[email protected]> wrote: > > > On 3 April 2016 at 23:30, Thierry Goubier <[email protected]> > wrote: > >> Le 03/04/2016 21:58, Igor Stasenko a écrit : >> >>> >>> >>> On 3 April 2016 at 22:32, Thierry Goubier <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Le 03/04/2016 20:01, Igor Stasenko a écrit : >>> >>> >>> >>> On 3 April 2016 at 20:51, Thierry Goubier >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> >>> Le 03/04/2016 19:12, Igor Stasenko a écrit : >>> >>> >>> >>> On 3 April 2016 at 19:48, Thierry Goubier >>> <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>> <mailto:[email protected] >>> <mailto:[email protected]> >>> >>> <mailto:[email protected] >>> <mailto:[email protected]>>>> wrote: >>> >>> Le 03/04/2016 17:33, stepharo a écrit : >>> >>> If you want to change clicking behaviour you >>> need to >>> override >>> one single >>> method. >>> >>> >>> Everything you wrote with >>> unreadable amount of >>> characters is >>> for nothing. >>> >>> I see clearly point of Igor. And for >>> me it >>> feels very >>> logical. >>> With such design you can lively change >>> clipping area and >>> interaction area for any morph >>> (element) on >>> screen. >>> >>> >>> In short, i see only two cases where >>> indeed, morph >>> requires >>> a nothing >>> of shapes to define: >>> - clipping region(s) >>> - ui interaction region(s) >>> >>> but for drawing? nooooo... really? who >>> cares what >>> you draw >>> there? >>> draw anything, in any possible way you see >>> fit.. >>> compose, >>> decompose, >>> recombine, blend and mix.. that's the >>> whole purpose of >>> drawing and be >>> artistic and be able to express yourself >>> in any >>> possible way >>> you want :) >>> Why nailing and formalizing things that >>> are tend to >>> be hardly >>> formalizable and more than that, >>> unnecessary. >>> That's my main concern about current >>> design. >>> >>> >>> I agree. >>> I do not see why people are forced to create a >>> submorph >>> just to >>> change >>> the rendering. >>> If you want to change it dynamically you can >>> for >>> example pass a >>> different shape. >>> >>> >>> I don't see the problem with subclassing a morph. >>> >>> Me neither. But do you confusing subclassing and >>> submorph >>> compositing? >>> >>> >>> Let me return you the question then: do you do a >>> composition of >>> submorphs if you're trying to get a different drawOn:? >>> >>> Who, me? No. Maybe i was just misunderstood your reply. >>> Because what i was tried to demonstrate in previous post(s) that >>> there's >>> simply no easy way to expose all possible drawing operations via >>> composition of morphs (or composition of any other kind of >>> elements), >>> unless, of course you will lift full feature set of Athens to >>> the level >>> of composition.. >>> As result you will get a full feature set that Athens provides, >>> plus >>> extra complexity. >>> Sounds like thing to do, no? :) >>> >>> >>> Agreed :) >>> >>> Oh, ok, that's true FastTable does it for the selection... >>> changing >>> background color by encapsulating a row in another Morph >>> with the >>> right background color. >>> >>> Well, i don't know what is FastTable beast are.. so i cannot >>> comment on >>> this one. >>> >>> >>> I think FastTable is something you should have a look at. Esteban >>> did something really interesting there. >>> >>> In FT, Submorphs are only created when they are about to be >>> displayed: Pharo can easily create hundreds of morphs on every >>> redraw cycle. So FT performance is O(k) where k is the number of >>> rows to display on screen (typical k is ~25), and is O(1) regarding >>> the length of the list (almost: there is a point, for very large >>> tree-like structures, where just iterating over the structure >>> becomes the main performance limitation: see FTTree). >>> >>> Sounds like right way to do it. There's no point to keep million UI >>> elements for million items in list, since you never render them all at >>> once on the screen. So, practical approach is to create as many UI >>> elements as fits on the screen, but not as many you have in list. >>> >>> A FTTableContainerMorph recreates all its submorphs on every >>> drawOn:. I've played with different variants (do not recreate all >>> submorphs, for example) but you don't see any performance difference >>> (on the time needed for a drawOn:). >>> >> >> Well, as Henrik pointed out, not everytime ;) >> >> Yeah, i did similar thing in TxText - also create morph(s) only for part >>> of text which is currently displayed.. and basically it is same idea for >>> TxText itself: it calculates layout only for a portion of text, the >>> portion that currently displayed, but never for whole text, which can be >>> megabytes long. >>> Thus, it guarantees that overall performance are bound to the area, >>> covered by UI control that displays the text, but not to text size. >>> >> >> I'm interested to know how you handle scrolling then: how do you define >> the step, the length and the position: relative to the number of characters >> displayed / start character of the current UI / and knowing the number of >> characters in the whole text, so that you are independent of the layout? >> >> > The scroll is defined in delta in pixels. So, scrolling single line - you > scroll by top or bottom line height (depending on direction). >
Or maybe i lying here.. i could be 'scroll up/down' until next/previous line are fully visible in layout. (There's of course an edge case, when line height is bigger than viewport height) > Scrolling page - you scroll by using height of viewport. No need to count > lines of text. > And so, i scan text forward or backward until new layout fully covers part > of text after such scrolling. And after it deleting portion of layout that > became invisible due to scrolling. > > The layout has anchor point in text - a position. And then dimensions > (width and height) and offset (a delta horizontal or vertical relative to > perfect condition when a position in text corresponds to 0,0 point in > layout ) > > The only place where i needed to measure text size was to positioning a > scrollbar knob to represent its size & vertical position approximately > close to where you in text and text size. And i really don't like that, > since it requires scanning whole text.. But well... tradeoffs.. It win > anyways, since i succeeded to avoid most operations to be bound to text > size. And only few left, that you cannot avoid. > > Regards, >> >> Thierry >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
