[Pharo-users] [ann] gt diagrammer
Hi, We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc. It looks like this: https://twitter.com/feenkcom/status/976341449267531776 We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick. One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this: https://twitter.com/feenkcom/status/982656456968241152 The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon. We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements. Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions. There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors. To play with it, the easiest way is to download the new GT in a Pharo 6.1 image: Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. And then inspect: GtDiagrammerElement new Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."
[Pharo-users] Did magritte change? Magritte-Morph-SeasnDeNigris.95 is not found
Because now when I load pillar Metacello new baseline: 'Pillar'; repository: 'github://pillar-markup/pillar:newpipeline/src'; load I get an error because Magritte-MOrph-SeasnDeNigris.95 is not found So I cannot build pillar anymore! :(
Re: [Pharo-users] Black screen on Mac OSX
Hi Hilaire The app goes to the dock but nothing happens. What is strange is that it is assigned to none display. I tried to open the drgeo.image with my working Pharo6.1VM and it did not work. I tried to open the drgeo.image with my working Pharo70VM and it did not work. => did not open. I could open one of my Phaor 70 images with the VM you ship. I have no log files or others. So I do not know what to do. Stef On Thu, Apr 5, 2018 at 10:34 AM, Hilaire wrote: > Le 04/04/2018 à 12:13, Stephane Ducasse a écrit : >> >> Let me know for P7 because this is easier to check and help. > > Ah, so please test this one on your Mac. It is a P7 image based built: > https://www.dropbox.com/s/f51fh7wa9x52grv/DrGeo.app-18.06a.zip?dl=0 > > > Thanks > > Hilaire > > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-users] installation of packages on 6.1
Hi hans did you succeed to download any other github stored projects? Stef On Thu, Apr 5, 2018 at 6:02 PM, Baveco, Hans wrote: > Trying to install Territorial the installation got stuck on the installation > of Roassal2 1.35, with error “LGitObjectNotInitialized” > > > > Transcript says: > > > > “Project: Roassal2 1.35 > > I got an error while cloning: There was an authentication error while trying > to execute the operation: error authenticating: failed connecting agent. > > This happens usually because you didn't provide a valid set of credentials. > > You may fix this problem in different ways: > > > > 1. adding your keys to ssh-agent, executing ssh-add ~/.ssh/id_rsa in your > command line. > > 2. adding your keys in settings (open settings browser search for "Use > custom SSH keys" and > > add your public and private keys). > > 3. using HTTPS instead SSH (Just use an url in the form HTTPS://etc.git). I > will try to clone the HTTPS variant.” > > > > I have encountered this several times before, for different packages (on > windows 7, pharo 6.1 (Image: Pharo6.0 [Latest update: #60540])) and have no > idea how to deal with this. > > > > Any suggestions? > > > > Hans
Re: [Pharo-users] Slower
Thanks for your analysis.
Should we open a enhancement issue for UFFI?
Stf
On Thu, Apr 5, 2018 at 4:09 PM, Henrik Sperre Johansen
wrote:
> HilaireFernandes wrote
>> After some more investigation, I think it is not the greated bottleneck.
>>
>> When I render points not as discs but as Square, Athens is happy. I
>> guess the Cairo way of doing this is very slow because its seems Cairo
>> does not come with dedicated disc rendering code, it must be render with
>> portion of arc, as far as I remember.
>>
>> If I prevent to render empty text label attached with each point, Athens
>> is even happier. Text font rendering through Athens seems to be slow.
>>
>> Hilaire
>>
>>
>> Le 04/04/2018 à 23:05, Hilaire a écrit :
>>> It reduces by 50% the time to execution. Need to check if this trick
>>> #1 and #2 are still needed at P7 time.
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>
> My notes after looking at the profile for a short while, if anyone feels the
> urge to optimize;
> UFFI:
>
>> 8.8% {11475ms}
>> CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y:
>> | 4.7% {6098ms} ExternalAddress>>packToArity:
>> | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease
>> | 2.6% {3439ms} ExternalAddress>>unpackFromArity:
>
> The lifespan of arguments that need arity packing/unpacking is well known,
> rewriting to use explicit free should lessen the overhead somewhat.
>
> CAIRO:
>
>> 26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to:
>>| 12.2% {15842ms} CairoGlyphsArray class>>new:
>
> With this kind of overhead just to create the array to hold results, it
> might be worthwhile to use a buffer array (of sufficient size) for the
> primitive, and copyFrom:to: to return the actual glyphs...
>
> DRGEO:
>
>> 20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas:
>>|16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:
>
> Storing the path in DrGPointMorph, rather than recreating for each draw:,
> should save alot of time.
>
>
>> 7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas:
>> | 7.7% {9962ms} Form>>asAthensPaintOn:
>
> Same thing here, only storing the paint, rather than converting from form
> each draw.
>
> Cheers,
> Henry
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
Re: [Pharo-users] line drawing bug
Check the examples around Athens.
On Fri, Apr 6, 2018 at 4:48 PM, wrote:
>
> That worked, thank you so much! This helps me get running in the interim
> while i investigate how to use Athens.
>
>
> { jb }
>
> On Apr 6, 2018, 9:31 AM -0400, Nicolai Hess , wrote:
>
> Hi Joe,
>
> the problem is that the BalloonCanvas (or some objects it is using) aren't
> fully reset after some drawing operations.
> (the drawString method for example sets the sourceForm as glyph to be
> drawn).
>
> it should work if you do not store the canvas instance, but create a new in
> every loop:
>
> points do: [ :p |
>
>canvas := form getCanvas asBalloonCanvas aaLevel:4; yourself.
>
>canvas drawPolygon: p
> color: Color transparent
> borderWidth: 1
> borderColor: Color red.
>
>canvas drawString: p first asString
> at: p first
> font: nil
> color: Color green.
> ].
>
>
>
>
> Or just reset the engine state (but I don't like this solution, the engine
> state should be private to the canvas).
>
> points do: [ :p |
>
>canvas drawPolygon: p
> color: Color transparent
> borderWidth: 1
> borderColor: Color red.
>
>canvas drawString: p first asString
> at: p first
> font: nil
> color: Color green.
>canvas resetEngine.
> ].
>
>
>
>
>
> 2018-04-06 2:57 GMT+02:00 :
>>
>> Hello everyone!
>>
>> Im trying use the balloon canvas to draw some nice smooth anti aliased
>> lines, but now i seem to have hit upon a bug which i dont know how to fix.
>>
>> if i draw just lines i get everything i want. but if i add a
>> “drawString:…” in there at any point, all the lines i try to draw
>> subsequently dont show up.
>>
>> Here is code that shows the exact issue:
>>
>> form := Form extent: 100@100 depth: 32.
>> form fillWhite.
>> canvas := BalloonCanvas on: form.
>> canvas aaLevel: 4.
>> "canvas := FormCanvas on: form."
>> points := { {10@10 . 50@43} . {50@42 . 90@75} . {90@75 . 50@90 } }.
>>
>> points do: [ :p |
>>canvas drawPolygon: p
>> color: Color transparent
>> borderWidth: 1
>> borderColor: Color red.
>>
>>canvas drawString: p first asString
>> at: p first
>> font: nil
>> color: Color green.
>> ].
>>
>> morph := ImageMorph new.
>> morph image: form.
>> morph openCenteredInWorld.
>>
>>
>>
>> if i comment out the canvas drawstring i get what you would expect: a
>> squiggly line.
>>
>> if i add in the drawstring, the first line shows up but all the subsequent
>> lines do not get drawn. (both images attached)
>>
>> I spent a bunch of time tracking it down to its most purest form and then
>> a bunch of time debugging it and im out of my depth with the baloon code, i
>> cant seem to figure out whats wrong. if anyone knows whats wrong or can
>> give me a clue on how to fix it i’d greatly appreciate it.
>>
>> thanks in advance.
>>
>>
>> { jb }
>
>
[Pharo-users] SmalltalkCI now supports loading tonel-based projects
Hi, SmalltalkCI now supports loading tonel-based projects, so feel free to start using it. The configuration is still the same. Please note that coveralls support for tonel is not yet in place, but that's just a cherry on top. :-) Cheers, Peter
Re: [Pharo-users] Plans for XSD in XML(Parser) the foreseeable future?
No problem, I've imagined this would be the case. Thanks, Peter On Fri, Apr 6, 2018 at 3:44 PM, monty wrote: > Unfortunately not. It's a major effort, and I'm not able to devote the > time to it now. > >
Re: [Pharo-users] configurable space in XML Writer tag
> It's changed to no longer emit that space. Thank you, however this could cause trouble for people needing the space. :) Making it configurable makes a lot of sense if you version your XML files (with e.g. git) and interchange with other tools... that way you can produce same formatting from both tools and not create false changes. Thanks! Peter On Fri, Apr 6, 2018 at 10:42 PM, monty wrote: > It's changed to no longer emit that space. I was considering removing it, > or at least making it configurable, anyway. > >
