April 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Athens Re: TxText model

by Igor Stasenko

On 7 April 2016 at 13:10, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-04-07 11:15 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> On 7 April 2016 at 10:32, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >>> >>> >>> 2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> >>>> >>>> On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks Igor. >>>>>>> Maybe some more Info? (I don't have much experience with this and >>>>>>> don't fully understand what is missing). >>>>>>> >>>>>>> >>>>>>>> 1. No support for vector graphics >>>>>>>> >>>>>>> >>>>>>> I know some parts of Athens (with Cairo font renderer and how it is >>>>>>> used in TxText) but at the moment >>>>>>> rendering a TextMorph in Athens works: >>>>>>> Morph comment asText asMorph openInSceneView >>>>>>> >>>>>> >>>>>> Sorry, missed to reply to that important point. >>>>>> It works because one good soul spent effort and helped me to finish >>>>>> implementation of a wrapper for Morph, to be able to render any morph into >>>>>> Form, and then render Form >>>>>> on Athens surface. >>>>>> >>>>> >>>>> Nah, actually it works a bit different. Many (Form)Canvas methods are >>>>> reimplemented on Athens API. But yes, I used some hacks as well. >>>>> >>>>> >>>> >>>> Didn't knew. >>>> Aha.. i see AthensCanvasWrapper. >>>> Ohh.. that's so much pain :) >>>> >>>> >>> As you are here and in a good mood for feedback, can you please answer >>> some >>> Athens questions or review some code changes / issue entries? >>> >>> I added some instance variables for AthensCairoPatternPaint >>> (origin, extent) This was needed for converting Morphics >>> GradientFillStyle to Athens pattern >>> paint. But I am unsure if this was the intended way to use them. >>> >>> There are protocols for creating gradient paints in Athens: >> >> createLinearGradient: aColorRamp start: aStartPoint stop: aStopPoint >> createRadialGradient: colorRamp center: aCenter radius: aRadius >> focalPoint: fp >> >> how you storing things inside or transform this information is orthogonal. >> From that perspective, anything what happens in AthensCairoPatternPaint >> is implementation detail. >> If you think that this protocol is not sufficient to define gradients, >> then >> fix it.. What happens on concrete implementation is last thing that >> should worry about. >> >> From my POV , two points and color ramp is enough to define linear >> gradient. >> Things like extent is a derived data, that can be obtained via simple >> calculations from original data. That why it wasn't there in a first place. >> >> I am interested on issue >>> 14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior >>> is >>> on purpose ,but I am not sure). >>> >>> >> The intent was to make clipping work with Morphic.. >> > > Hm, I still don't know if the outcome was intended. > If you compare the two example codes, > the first defines a cliprect > translates the path transform > draws a rectangle (the green one), this rectangle is clipped (that is, the > cliprect is not translated - OK) > > The second example does the same, but defines again a cliprect after the > path transform. Now the rectangle is not clipped (by the first clip rect), > although the comment in > AthensCanvas says > "Note that the clipping rectangle is intersected with the currently active > clipping rectangle" > > If i remember the intent was to demonstrate that you can nest clipping operations. Ideally that should work as: - you clip in local coordinates - then you can translate/transform coordinates again - and again clip, but in new coordinates, but that still take into account the outer clipping. IIRC, Cairo doesn't allows nesting for clipping.. but i may be mistaken. -- Best regards, Igor Stasenko.

April 7, 2016

Re: [Pharo-dev] Athens Re: TxText model

by Aliaksei Syrel

On Thu, Apr 7, 2016 at 12:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Do we need an AthensCanvas>>#isVisible: ? Yes. There is no need to draw morphs that are outside of current clip area. That is why we have: fullDrawOnSpartaCanvas: aCanvas > (self isVisibleOnCanvas: aCanvas) > ifFalse: [ ^ self ]. . . . Even if it would not speed up extent calculations, I would prefer too, to > have EllipsePath, PolygonPath, ..., It is much more convenient to work with > explicit classes than to define everything with a Path, even > if everything is just a Path :-) I too :) It also helps during debugging and inspection, having that we can mold tools with custom presentations for Path. Cheers, Alex

April 7, 2016

Re: [Pharo-dev] Athens Re: TxText model

by Nicolai Hess

2016-04-07 11:52 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > > On Thu, Apr 7, 2016 at 11:15 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> That may, indeed make accessing such properties like clipRect impossible >> to get, since clipped area cannot be represented by a simple rectangle >> anymore. >> But then you could, perhaps instead provide a protocol to tell if given >> point/bounds/shape is fully outside currently clipped region(s) or not. >> And thus, you don't have to worry about cliprect anymore. >> > > In Sparta I use cairo_clip_extents to get current clip rect in local > coordinates. Together with cairo_path_extents, implementation of > AthensCanvas#>>#isVisible: becomes trivial even for arbitrary path (+ > assuming that Rectangle is polymorphic with Path). > Do we need an AthensCanvas>>#isVisible: ? > > Btw, for simple paths (circle, ellipse, text, rectangle) it is an overkill > to ask cairo for path extent that is why it makes sense for optimisation to > have subclasses of Path like EllipsePath, PolygonPath and calculate extent > in Pharo. If user uses Factory than extent detection degrades to > cairo_path_extents. > Even if it would not speed up extent calculations, I would prefer too, to have EllipsePath, PolygonPath, ..., It is much more convenient to work with explicit classes than to define everything with a Path, even if everything is just a Path :-) > > So, in Sparta (now it is still BlPath) there is Path>>#bounds that by > default uses cairo_path_extents, still allowing user to override it and > implement optimised Pharo version :) > > Cheers, > Alex >

April 7, 2016

Re: [Pharo-dev] Athens Re: TxText model

by Nicolai Hess

2016-04-07 11:15 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 7 April 2016 at 10:32, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> >> >> 2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >> >>> >>> >>> On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>>> >>>>> >>>>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> Thanks Igor. >>>>>> Maybe some more Info? (I don't have much experience with this and >>>>>> don't fully understand what is missing). >>>>>> >>>>>> >>>>>>> 1. No support for vector graphics >>>>>>> >>>>>> >>>>>> I know some parts of Athens (with Cairo font renderer and how it is >>>>>> used in TxText) but at the moment >>>>>> rendering a TextMorph in Athens works: >>>>>> Morph comment asText asMorph openInSceneView >>>>>> >>>>> >>>>> Sorry, missed to reply to that important point. >>>>> It works because one good soul spent effort and helped me to finish >>>>> implementation of a wrapper for Morph, to be able to render any morph into >>>>> Form, and then render Form >>>>> on Athens surface. >>>>> >>>> >>>> Nah, actually it works a bit different. Many (Form)Canvas methods are >>>> reimplemented on Athens API. But yes, I used some hacks as well. >>>> >>>> >>> >>> Didn't knew. >>> Aha.. i see AthensCanvasWrapper. >>> Ohh.. that's so much pain :) >>> >>> >> As you are here and in a good mood for feedback, can you please answer >> some >> Athens questions or review some code changes / issue entries? >> >> I added some instance variables for AthensCairoPatternPaint >> (origin, extent) This was needed for converting Morphics >> GradientFillStyle to Athens pattern >> paint. But I am unsure if this was the intended way to use them. >> >> There are protocols for creating gradient paints in Athens: > > createLinearGradient: aColorRamp start: aStartPoint stop: aStopPoint > createRadialGradient: colorRamp center: aCenter radius: aRadius > focalPoint: fp > > how you storing things inside or transform this information is orthogonal. > From that perspective, anything what happens in AthensCairoPatternPaint is > implementation detail. > If you think that this protocol is not sufficient to define gradients, > then > fix it.. What happens on concrete implementation is last thing that should > worry about. > > From my POV , two points and color ramp is enough to define linear > gradient. > Things like extent is a derived data, that can be obtained via simple > calculations from original data. That why it wasn't there in a first place. > > I am interested on issue >> 14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior >> is >> on purpose ,but I am not sure). >> >> > The intent was to make clipping work with Morphic.. > Hm, I still don't know if the outcome was intended. If you compare the two example codes, the first defines a cliprect translates the path transform draws a rectangle (the green one), this rectangle is clipped (that is, the cliprect is not translated - OK) The second example does the same, but defines again a cliprect after the path transform. Now the rectangle is not clipped (by the first clip rect), although the comment in AthensCanvas says "Note that the clipping rectangle is intersected with the currently active clipping rectangle"

April 7, 2016

Re: [Pharo-dev] Athens Re: TxText model

by Aliaksei Syrel

On Thu, Apr 7, 2016 at 11:15 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > That may, indeed make accessing such properties like clipRect impossible > to get, since clipped area cannot be represented by a simple rectangle > anymore. > But then you could, perhaps instead provide a protocol to tell if given > point/bounds/shape is fully outside currently clipped region(s) or not. > And thus, you don't have to worry about cliprect anymore. > In Sparta I use cairo_clip_extents to get current clip rect in local coordinates. Together with cairo_path_extents, implementation of AthensCanvas#>>#isVisible: becomes trivial even for arbitrary path (+ assuming that Rectangle is polymorphic with Path). Btw, for simple paths (circle, ellipse, text, rectangle) it is an overkill to ask cairo for path extent that is why it makes sense for optimisation to have subclasses of Path like EllipsePath, PolygonPath and calculate extent in Pharo. If user uses Factory than extent detection degrades to cairo_path_extents. So, in Sparta (now it is still BlPath) there is Path>>#bounds that by default uses cairo_path_extents, still allowing user to override it and implement optimised Pharo version :) Cheers, Alex

April 7, 2016

Re: [Pharo-dev] Athens Re: TxText model

by Igor Stasenko

On 7 April 2016 at 10:32, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >>> >>> >>> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> >>>> >>>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> Thanks Igor. >>>>> Maybe some more Info? (I don't have much experience with this and >>>>> don't fully understand what is missing). >>>>> >>>>> >>>>>> 1. No support for vector graphics >>>>>> >>>>> >>>>> I know some parts of Athens (with Cairo font renderer and how it is >>>>> used in TxText) but at the moment >>>>> rendering a TextMorph in Athens works: >>>>> Morph comment asText asMorph openInSceneView >>>>> >>>> >>>> Sorry, missed to reply to that important point. >>>> It works because one good soul spent effort and helped me to finish >>>> implementation of a wrapper for Morph, to be able to render any morph into >>>> Form, and then render Form >>>> on Athens surface. >>>> >>> >>> Nah, actually it works a bit different. Many (Form)Canvas methods are >>> reimplemented on Athens API. But yes, I used some hacks as well. >>> >>> >> >> Didn't knew. >> Aha.. i see AthensCanvasWrapper. >> Ohh.. that's so much pain :) >> >> > As you are here and in a good mood for feedback, can you please answer some > Athens questions or review some code changes / issue entries? > > I added some instance variables for AthensCairoPatternPaint > (origin, extent) This was needed for converting Morphics GradientFillStyle > to Athens pattern > paint. But I am unsure if this was the intended way to use them. > > There are protocols for creating gradient paints in Athens: createLinearGradient: aColorRamp start: aStartPoint stop: aStopPoint createRadialGradient: colorRamp center: aCenter radius: aRadius focalPoint: fp how you storing things inside or transform this information is orthogonal. >From that perspective, anything what happens in AthensCairoPatternPaint is implementation detail. If you think that this protocol is not sufficient to define gradients, then fix it.. What happens on concrete implementation is last thing that should worry about. >From my POV , two points and color ramp is enough to define linear gradient. Things like extent is a derived data, that can be obtained via simple calculations from original data. That why it wasn't there in a first place. I am interested on issue > 14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior is > on purpose ,but I am not sure). > > The intent was to make clipping work with Morphic.. This is true that morphic needs cliprect to be smart and not try to draw anything if it is fully outside clipped areas.. So, this is purely for optimization purpose. But i would prefer to have a consistent clipping model first, i.e.: - clipping using local coordinates - you can use any shape for clipping and then think how to adapt users with their concrete cases. That may, indeed make accessing such properties like clipRect impossible to get, since clipped area cannot be represented by a simple rectangle anymore. But then you could, perhaps instead provide a protocol to tell if given point/bounds/shape is fully outside currently clipped region(s) or not. And thus, you don't have to worry about cliprect anymore. AthensPathSegment: > I understand how they use the visit: messages but I don't understand the > #accept: or the #sendCommandTo: methods, are they used? > > The intent is to use it for path conversion/transformation etc. It is because we cannot guarantee that all backends will support various kinds of path segments, that Athens providing to user. And so, we need a small private toolset for converting some segments into simpler form, in case of need. So , it is there when you need to iterate over path for things like converting it to polygon etc. But that part needs review and cleanup, because it smells... Aliaksei fixed a bug in > CairoFreetypeFontRenderer>>#glyphsOf:from:to: > (the bug was: sometimes, some characters uses glyphs with wrong size). > > I think some AthensText classes are obsolete: > AthensTextScanner/AthensParagraph/AthensTextMorph/AthensPluggableTextMorph > Can we remove them? > > Well, if i remember, there are some leftovers from attempt to make text rendering it at least partially work with Balloon backend. While some other is result of failed attempt to make anything with TextMorph. So, nobody will cry if you clean this mess. -- Best regards, Igor Stasenko.

April 7, 2016

canc/del closes windows

by Davide Varvello

Hi Guys, Is it only me that sometimes hitting canc/del closes the current window? It's really annoying, I'm on a mac and I guess it's related to cmd button because if I click the cmd button afterward, it disappears (until next time). I tried also on several macs but the result is the same. TIA Davide -- View this message in context: http://forum.world.st/canc-del-closes-windows-tp4888805.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 7, 2016

Re: [Pharo-dev] Project Catalog questions

by Cyril Ferlicot Delbecque

On 07/04/2016 05:53, HernÃ¡n Morales Durand wrote: > Hi all, > Hi! > Is there a specific reason why Project Catalog items menu does not > include "Install development version" and/or "Install bleeding edge" > options? > I think that the reason is just nobody did it. > Another one is, what does it mean the "Install stable version and create > group" option? group of what? what for? > On Pharo 5 in your Nautilus you have groups in the top of the packages pane. For example there is a group for Configurations and Baselines. You can load the project and create a group in order to have one item in Nautilus for all the packages of the loaded project. > HernÃ¡n > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

April 7, 2016

Athens Re: TxText model

by Nicolai Hess

2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > > > On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> >> >> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: >> >>> >>> >>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>>> >>>> >>>> Thanks Igor. >>>> Maybe some more Info? (I don't have much experience with this and don't >>>> fully understand what is missing). >>>> >>>> >>>>> 1. No support for vector graphics >>>>> >>>> >>>> I know some parts of Athens (with Cairo font renderer and how it is >>>> used in TxText) but at the moment >>>> rendering a TextMorph in Athens works: >>>> Morph comment asText asMorph openInSceneView >>>> >>> >>> Sorry, missed to reply to that important point. >>> It works because one good soul spent effort and helped me to finish >>> implementation of a wrapper for Morph, to be able to render any morph into >>> Form, and then render Form >>> on Athens surface. >>> >> >> Nah, actually it works a bit different. Many (Form)Canvas methods are >> reimplemented on Athens API. But yes, I used some hacks as well. >> >> > > Didn't knew. > Aha.. i see AthensCanvasWrapper. > Ohh.. that's so much pain :) > > As you are here and in a good mood for feedback, can you please answer some Athens questions or review some code changes / issue entries? I added some instance variables for AthensCairoPatternPaint (origin, extent) This was needed for converting Morphics GradientFillStyle to Athens pattern paint. But I am unsure if this was the intended way to use them. I am interested on issue 14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior is on purpose ,but I am not sure). AthensPathSegment: I understand how they use the visit: messages but I don't understand the #accept: or the #sendCommandTo: methods, are they used? Aliaksei fixed a bug in CairoFreetypeFontRenderer>>#glyphsOf:from:to: (the bug was: sometimes, some characters uses glyphs with wrong size). I think some AthensText classes are obsolete: AthensTextScanner/AthensParagraph/AthensTextMorph/AthensPluggableTextMorph Can we remove them? > > >> So, that is why it 'works' :) >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

April 7, 2016

Re: [Pharo-dev] TxText model

by Igor Stasenko

On 6 April 2016 at 21:49, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > The only thing required for styling is to specify the attributes for the > runs associated with the text. > > A simple example: > > > > | text attributes oldRuns clr| > > > > text := (String loremIpsum: 1234) asText. > > > > attributes := Array new: text size. > > > > clr := TextColor color: Color random. > > > > 1 to: text size do: [ :index | > > attributes at: index put: { > > clr. > > TextFontChange font2 > > }. > > > > (text at: index) isSeparator ifTrue: [ clr := TextColor > color: Color random ] > > ]. > > > > text runs: (RunArray newFrom: attributes). > > > > text > > > Same for TxText: | text selection | text := (String loremIpsum: 1234) asTxModel. selection := text newSelection. "set font to whole text" selection applyAttribute: (TxFontAttribute with: MyFont). selection end moveToStart. [ selection end isAtEnd ] whileFalse: [ selection end moveDown. selection applyAttribute: (TxForeColorAttribute with: Color random). selection start: selection end. ]. text editInWindow > > Best regards, > > Henrik > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Nicolai Hess > *Sent:* Wednesday, April 6, 2016 8:23 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] TxText model > > > > > > > > 2016-04-06 18:11 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > Ok. Call me stupid but in Pharo I don't see how to do that easily. > > > > Phil > > > > At least for Rubric, it can not be that difficult. I saw a GT-Inspector > with a XML-styer > > > > > > On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > > On 06-04-16 11:13, phil(a)highoctane.be wrote: > > Another pain is the styling of text where the only styler we have is the > SHSt80Styler (class name out of my mind, need to check) and that's a huge > pain to support other stylings. > > > Styling with different stylers worked in TextMorph. In Squeak it is easy > to add styling for a different language in the class browser. Levente did > that for PostgreSQLv3. > > Stephan > > > > > -- Best regards, Igor Stasenko.

April 7, 2016