April 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Versionner screencast

by Stephan Eggermont

Hi Christophe Nice presentation. Showing how Versionner is supposed to be used is very helpful. Stephan

April 23, 2014

Re: [Pharo-users] Modal widget

by Esteban Lorenzano

which now I remember I always complemented it âweb-likeâ: I added a transparent sticky morph behind, so all the morphs become unaccessibleâ¦ I do not remember why I needed it, thought. Esteban On 23 Apr 2014, at 10:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > look at the implementation of #callInWorld for Magritte-Morph. > I always liked that solution :) > > Esteban > > On 23 Apr 2014, at 10:46, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > >> Hello, >> >> In a morph hierarchy I would like one morph child to be modal (i.e. all >> other morphs are locked and the system is waiting for the user action on >> this modal morph). >> >> I need this for dialog encrusted in a parent morph (instead of windowed >> dialog flying around the system). >> In the screen shot example, only the "ok" button is actionable. >> >> I can hack with appropriate lock and unlock in the morph hierarchy, but >> it is not clean and not exactly modal because the system does not wait >> for the user answer. >> >> Any idea to do it more cleanly? >> >> Thanks >> >> Hilaire >> >> >> >> -- >> Dr. Geo http://drgeo.eu >> <modalWidget.jpeg> >

April 23, 2014

Re: [Pharo-users] Modal widget

by Esteban Lorenzano

look at the implementation of #callInWorld for Magritte-Morph. I always liked that solution :) Esteban On 23 Apr 2014, at 10:46, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Hello, > > In a morph hierarchy I would like one morph child to be modal (i.e. all > other morphs are locked and the system is waiting for the user action on > this modal morph). > > I need this for dialog encrusted in a parent morph (instead of windowed > dialog flying around the system). > In the screen shot example, only the "ok" button is actionable. > > I can hack with appropriate lock and unlock in the morph hierarchy, but > it is not clean and not exactly modal because the system does not wait > for the user answer. > > Any idea to do it more cleanly? > > Thanks > > Hilaire > > > > -- > Dr. Geo http://drgeo.eu > <modalWidget.jpeg>

April 23, 2014

Modal widget

by Hilaire Fernandes

Hello, In a morph hierarchy I would like one morph child to be modal (i.e. all other morphs are locked and the system is waiting for the user action on this modal morph). I need this for dialog encrusted in a parent morph (instead of windowed dialog flying around the system). In the screen shot example, only the "ok" button is actionable. I can hack with appropriate lock and unlock in the morph hierarchy, but it is not clean and not exactly modal because the system does not wait for the user answer. Any idea to do it more cleanly? Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 23, 2014

Re: [Pharo-users] Error when trying to initiate Pharo in Ubuntu 64 bits

by GABRIEL DEFAGOT

Okay! Thank you all! :-) Date: Tue, 22 Apr 2014 15:47:44 +0100 From: sergi.reyner(a)gmail.com To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Error when trying to initiate Pharo in Ubuntu 64 bits 2014-04-22 15:26 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: http://files.pharo.org/vm/pharo/linux/pharovm-u804.tar.gz Whoever compiled it deserves commendation. Nevertheless, in my opinion itÂ´s an issue to keep in mind for the future; distributions are likely to upgrade their libc at different points in time, and a good lowest common denominator should be chosen with care, otherwise itÂ´s not really "common" at all. PS: in case itÂ´s not apparent IÂ´m not an Ubuntu fan :) Cheers,Sergi

April 23, 2014

Re: [Pharo-users] Athens and ellipse drawing

by stepharo

Thanks for the explanation I will add them to the chapter. On 22/4/14 14:05, Igor Stasenko wrote: > > > > On 14 April 2014 13:53, Juraj Kubelka <juraj.kubelka(a)gmail.com > <mailto:juraj.kubelka@gmail.com>> wrote: > > > El 14-04-2014, a las 8:21, Juraj Kubelka <juraj.kubelka(a)gmail.com > <mailto:juraj.kubelka@gmail.com>> escribiÃ³: > >> Thank you Stef, >> >> the example helped me a lot to understand how to play with Athens. >> >> The solution is not what I am looking for. If someone starts to >> play with alpha canal, s/he will get unexpected results. >> >> I have finally found an example in C language. It look like this: >> -=-=-=-=- >> cairo_set_line_width (cr, 0.1); >> cairo_save (cr); >> cairo_scale (cr, 1, 0.2); >> cairo_arc (cr, 1.5, 1.5, 1, 0, 2 * M_PI); >> cairo_restore (cr); >> cairo_set_source_rgba (cr, 0, 1, 0, 0.50); >> cairo_stroke (cr); >> -=-=-=-=- >> <tips-ellipse.png> >> >> I do not know how to write the same instructions with Athens. >> >> First, they draw one arc (cairo_arc (cr, 1.5, 1.5, 1, 0, 2 * >> M_PI);), I draw 4 arcs: >> -=-=-=-=- >> canvas >> createPath: [ :builder | >> builder >> absolute; >> moveTo: 0 @ 0.5; >> ccwArcTo: 0.5 @ 0.0 angle: 90 degreesToRadians; >> ccwArcTo: 0.0 @ -0.5 angle: 90 degreesToRadians; >> ccwArcTo: -0.5 @ 0.0 angle: 90 degreesToRadians; >> ccwArcTo: 0 @ 0.5 angle: 90 degreesToRadians ]. >> -=-=-=-=- > > OK, now I can draw ellipse with just one arc: > -=-=-=- > canvas > createPath: [ :builder | > builder > absolute; > moveTo: 0.5 @ 0; > arcCenterX: 0 centerY: 0 radius: 0.5 startAngle: 0 endAngle: Float > twoPi > -=-=-=- > > Why is this method in private protocol? Why I should not use it? > > > because its private.. and implementation specific. > other implementations may not have this method at all, and your code > will simply throw DNU. > And that's why you got the horizontal line btw.. because of using > private protocol bypassing coordinate tracking. > > Why I have to use âmoveTo:â? In C-example they do not use it. But > I have to, otherwise there is an extra line on the canvas: > > Well, I see in AthensCairoPathBuilder>>createPath:, there is call > of "self moveToX: 0 Y: 0.â. If I remove it, I do not have to write > âmoveTo: 0.5@0â. So, I understand why I have to write it in my > code. The question is what is the purpose of "self moveToX: 0 Y: > 0.â? I guess it simplify some situations, am I right? Which one? > > > the initial moveTo: command lets you set the origin (starting point) > of your path. > if you don't start path with moveTo: command, it is implicitly set to 0@0. > > > There is actual Athens example: > -=-=-=- > AthensSceneView new scene: [ :can | > | path | > path := can createPath: [ :builder | > builder > absolute; > moveTo: 0.5 @ 0; > arcCenterX: 0 centerY: 0 radius: 0.5 startAngle: 0 endAngle: Float > twoPi ]. > can pathTransform restoreAfter: [ > can pathTransform scaleBy: 200 @ 50. > > (can setStrokePaint: Color red) width: 0.1. > can drawShape: path. > ]. > ] ; > openInWindow > -=-=-=- > > Thank you, > Juraj > >> >> Second, they set line width, before any other action (like >> cairo_save). I do: >> -=-=-=-=- >> canvas pathTransform scaleBy: 200 @ 50. >> (can setStrokePaint: Color red) *width: 0.1*. >> can drawShape: path. >> -=-=-=-=- >> >> So, my result in Athens is like this: >> <Captura de pantalla 2014-04-14 a la(s) 8.18.38.png> >> >> Any idea? The example is explained here >> <http://cairographics.org/tutorial/#L2linewidth>, C source code >> is here <http://cairographics.org/tutorial/tips-ellipse.c> (by >> clicking on the image in the page >> <http://cairographics.org/tutorial/#L2linewidth>). >> >> Thank you, >> Jura >> >> El 12-04-2014, a las 4:01, Pharo4Stef <pharo4Stef(a)free.fr >> <mailto:pharo4Stef@free.fr>> escribiÃ³: >> >>> AthensSceneView new >>> scene: [ :can | >>> | path | >>> path := can >>> createPath: [ :builder | >>> builder >>> absolute; >>> moveTo: 0 @ 0.5; >>> ccwArcTo: 0.5 @ 0.0 angle: 90 degreesToRadians; >>> ccwArcTo: 0.0 @ -0.5 angle: 90 degreesToRadians; >>> ccwArcTo: -0.5 @ 0.0 angle: 90 degreesToRadians; >>> ccwArcTo: 0 @ 0.5 angle: 90 degreesToRadians ]. >>> >>> can pathTransform >>> restoreAfter: [ >>> can pathTransform scaleBy: 200 . >>> can >>> setPaint: Color red ; >>> drawShape: path. >>> "(athensCanvas setStrokePaint: strokePaint) >>> width: (self strokeWidth / self scale) asFloat." >>> can drawShape: path.]. >>> can pathTransform >>> restoreAfter: [ >>> can pathTransform scaleBy: 190 . >>> can >>> setPaint: Color blue ; >>> drawShape: path. >>> "(athensCanvas setStrokePaint: strokePaint) >>> width: (self strokeWidth / self scale) asFloat." >>> can drawShape: path >>> >>> ] >>> ] ; >>> openInWindow >>> >>> >>> <Screen Shot 2014-04-12 at 09.01.09.pdf> >> > > > > > -- > Best regards, > Igor Stasenko.

April 22, 2014

Re: [Pharo-users] Athens question: AffineTransform, AthensCairoMatrix and Float values

by Igor Stasenko

On 11 April 2014 20:24, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Thank you Igor, > > I understand and I agree. Just can you clarify one think. Maybe I use it > wrong. Right now in Roassal2/Trachel a shape has instance variable called > matrix which is an AthensAffineTransform object. And if someone calls > translateBy:, or scaleBy:, etc. I call the appropriate method > on AthensAffineTransform. Do you say, that I should rather have instance > variables position, rotation, and scale? Do I understand well? I thought it > is better (faster) to keep the matrix and in #drawOn: only call > #multiplyBy:. > > it doesn't really matters.. and up to your convenience. sometimes it's convenient to use decomposed form (e.g. translation, scale, rotation) instead of full matrix, sometimes not.. depends how/who/where you using it. And another question. Right now a rectangle is drawn like this: > -=-=-=-=- > computePath > canvas ifNil: [ ^ self ]. > path := self athensCanvas > createPath: [ :builder | > builder > absolute; > moveTo: rectangle topLeft; > lineTo: rectangle topRight; > lineTo: rectangle bottomRight; > lineTo: rectangle bottomLeft; > lineTo: rectangle topLeft. ] > -=-=-=-=- > > I do not see a method which draws rectangle directly. This example<http://zetcode.com/gfx/cairo/shapesfills/> shows > there is a direct support for rectangle drawing. Am I right we do not have > that support in Athens? Is there a reason for it? > > Because there's only one method which draws any kind of shapes (including rectangle). All you need to do is to draw it: canvas drawShape: (0@0 corner: 100@100). or canvas setShape: (0@0 corner: 100@100). ... canvas draw. else there would be need to add dozens of drawRect: drawOval: drawZigZag: drawAnotherWeirdThing: instead of simple method which covers all. Thank you, Juraj El 11-04-2014, a las 13:29, Igor Stasenko <siguctua(a)gmail.com> escribiÃ³: On 11 April 2014 17:41, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi, > > We are integrating Athens transformation to Roassal2/Trachel and I have > reached an issue. > > In drawing code I use something like this: > -=-=-=- > athensCanvas pathTransform > restoreAfter: [ > *athensCanvas pathTransform* > *multiplyBy: matrix; âan instance of AthensAffineTransform"* > athensCanvas > setPaint: color; > drawShape: self path. > -=-=-=- > > I have a problem, that sometimes it crashes because it expects a float > value (I understand why). I suppose I do not have to keep float values in > AthensAffineTransform object. My suggestion is to ensure float values where > it is expected. For example the method #loadAffineTransform could be like > this: > > -=-=-=- > AthensCairoMatrix>>loadAffineTransform: m > self > initx: m x *asFloat* > y: m y *asFloat* > sx: m sx *asFloat* > sy: m sy *asFloat* > shx: m shx *asFloat* > shy: m shy *asFloat* > -=-=-=- > > Which will mean 6 extra #asFloat message sends, even if they're already floats or ints but not Fractions (and in 99% of cases they are, so you will slow down everything for the sake of 1%). I prefer that user supplies already prepared data, so it don't have to be implicitly converted since it takes extra CPU cycles, which can be spent somewhere else. But yes, it needs to be ensured, but at different place: where you building that AthensAffineTransform AthensAffineTransform>>sx: number sx := number =>>> AthensAffineTransform>>sx: number sx := number asFloat .. (and for the rest of accessors) like that it will ensure that AthensAffineTransform always stores floats, which i'm not really like because integers is perfectly fine too.. its all about Fractions. Right now I have to do that transformation myself whenever I use Athens > objects. I see it error prone and I do not see it obvious. > > On other hand I do not want to keep float values in my > AthensAffineTransform, because if user do #scaleBy: 0.7 and then #scaleBy: > (1/0.7) I want to get the same original value. Otherwise the image could > change its size. > > On your place i'd better forget about it. That's impossible when you dealing with floating point values.. and multiple matrix operations. Unless you explicitly control it by yourself, but that certainly should be outside of AthensAffineTransform/Athens. > The same change could be for other methods in AthensCairoMatrix. > > Again, that would mean dozens of extra message sends at every single place, whether it needed or not.. Like: AthensCairoMatrix>>translateX: px Y: py needs to be replaced with: ^ self primTranslateX: px asFloat Y: py asFloat instead of direct call, plus adding #primTranslateX:Y: method, of course. Do you really want to pay a price of 50% less performance (or more) in exchange of "i don't wanna think what i passing to it"? Because apparently, you always need to think what you passing - one cannot just pass a random object to some method and expect it to work, isn't? Because i don't. All you need is to avoid using Fractions.. because integers or floats is perfectly fine. Fraction created only if you use division on integer.. so all you need to do is to ensure the result of division is float: (x/y) asFloat. > What do you think? > I am biased towards having better performance, even at cost of inconvenience, where at some places i have to ensure i need to pass correct value(s). > Juraj > -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.

April 22, 2014

Re: [Pharo-users] Domaintalk - A Proposed New Project Second Attempt

by Sergi Reyner

2014-04-22 17:01 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Upload it to Dropbox or similar Cloud hosting. > > Send it to me and I can do it for you. Or just pastebin it.

April 22, 2014

Re: [Pharo-users] Domaintalk - A Proposed New Project Second Attempt

by Esteban A. Maringolo

Upload it to Dropbox or similar Cloud hosting. Send it to me and I can do it for you. Esteban A. Maringolo 2014-04-22 12:52 GMT-03:00 Bob Williams <rwilliams19(a)cox.net>: > It would appear that there is some interest in the Domaintalk project, but > from the responses I received it is clear you need to see my full proposal > to appreciate the scope of what is being proposed and determine if it is > something that the Pharo project wants to do. The more extensive is > currently over five pages of single spaced text and I think that that is > excessive for the body of an email and I am not sure if your email system > allows attachments. My problem is that I do not have access to a Web site; > therefore, I am looking for a place where I can post the proposal document. > > Some help please.

April 22, 2014

Domaintalk - A Proposed New Project Second Attempt

by Bob Williams

It would appear that there is some interest in the Domaintalk project, but from the responses I received it is clear you need to see my full proposal to appreciate the scope of what is being proposed and determine if it is something that the Pharo project wants to do. The more extensive is currently over five pages of single spaced text and I think that that is excessive for the body of an email and I am not sure if your email system allows attachments. My problem is that I do not have access to a Web site; therefore, I am looking for a place where I can post the proposal document. Some help please.

April 22, 2014