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

Re: [Pharo-dev] Rectangle Center

by Ben Coman

On Thu, Apr 30, 2015 at 4:53 AM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > > On Wed, Apr 29, 2015 at 5:42 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Ok, can we start form the test? >> >> Is it ok, that the test passes for rectangle with 10 @ 20 extent and >> fails for 15 @ 20 extent? >> >> > I would make it test both coordinates. > > i.e. test for 15 @ 15 extent > That would be 15@20 and 20@15. :) cheers -ben

April 29, 2015

Re: [Pharo-dev] TimeStamp deprecation and related frameworks (GLORP, Grease, Magritte, Seaside...)

by Esteban A. Maringolo

I uploaded a new development version (1.12) to the ConfigurationOfGlorp available at DBXTalk/Configurations repo that replaces the references to TimeStamp by DateAndTime. If anybody is willing to test it we can bless it as #stable. I used it and ran my tests against it and it caused no side effects so far. Esteban A. Maringolo 2015-04-29 15:36 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2015-04-29 12:49 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> On 29 Apr 2015, at 17:39, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> In the case of GLORP, which I'm updating too, TimeStamp use is more >>> extended, because it's also a datatype used to map table columns, but >>> using no timezone offset. I guess if we move to DateAndTime we should >>> preserve that behavior in order to not break anything. > >> I don't understand this last point, could you elaborate ? > >> As far as I see it, there is nothing TimeStamp did that DateAndTime cannot do. > > Me neither. But I simply don't wan't to break anything. :) > >>> ps: I'm so tempted to fork from the GLORP package, rename as something >>> else (PLORM?) and refactor it mercilessly. >> That is something else ;-) > > :)

April 29, 2015

Re: [Pharo-dev] Rectangle Center

by Sergio Fedi

On Wed, Apr 29, 2015 at 5:42 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Ok, can we start form the test? > > Is it ok, that the test passes for rectangle with 10 @ 20 extent and fails > for 15 @ 20 extent? > > I would make it test both coordinates. i.e. test for 15 @ 15 extent

April 29, 2015

Re: [Pharo-dev] Rectangle Center

by Yuriy Tymchuk

Ok, can we start form the test? Is it ok, that the test passes for rectangle with 10 @ 20 extent and fails for 15 @ 20 extent? Uko > On 29 Apr 2015, at 19:11, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2015-04-29 18:50 GMT+02:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>>: > > > On 29/04/15 15:18, Sean P. DeNigris wrote: > > Natalia Tymchuk wrote > >> Should it really be like that? > > > > The problem is that you can't have half-a-pixel if a dimension is odd > > > > For these situations, I would use the method #floor or #rounded of the > class Point, or create the method #roundedCenter, as Natalia suggested. > > Currently, the name of the class and the method communicate the wrong > behavior. > > Tommaso > > > Rectangle was and still is a primitive type known to low level graphics operations. > It's just that it pre-empts a word that is more generic than the implementation ;) > > You can't even rotate a rectangle... > It's just a clipping or viewport rectangle having same orientation as a rectangular target canvas (image, bitmap, screen or other device). > > Depending on what you are after, it's maybe not the right abstraction... > > That does not mean that Rectangle can't be changed. > That means that it must be carefully changed as long as it is used for the low level stuff... > > ...or it must be split. Maybe it's where namespaces might help. > > Nicolas > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/Rectangle-Center-tp4822883p4822891.html <http://forum.world.st/Rectangle-Center-tp4822883p4822891.html> > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. > >

April 29, 2015

Re: [Pharo-dev] Tx: Bold Text

by Nicolas Cellier

2015-04-29 21:32 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-04-29 18:04 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Nicolai Hess wrote >> > Assign the proper Attribute? >> >> Well AFAICT there is no bold attribute, > > > Ah yes, I mix up this with TextMorph and addAttribute:TextEmphasis.... > > >> but I tried setting the font to bold >> via "(LogicalFont familyName: 'Tahoma' pointSize: 9 + i) emphasis: 1; >> yourself." but it was rendered the same as before... >> >> > If the font is in the system, this should work. > > | text font1 font2 font3 string1 | > font1 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: > TextEmphasis normal emphasisCode. > font2 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: > TextEmphasis bold emphasisCode. > font3 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: > TextEmphasis italic emphasisCode. > If an emphasisCode is used at low level, that's fine, but shouldn't the API be more straight like: emphasis: aTextEmphasis or: emphasisCode: anIntegerOrSymbolOrLetterOrAnyOtherWayToCodeAnEmphasis Nicolas string1 := 'Normal Bold Italic '. > text := TxModel new. > text at: text startPosition insert: string1. > > (text startPosition selectTo: text startPosition + 7) > applyAttribute: (TxForeColorAttribute with: Color red); > applyAttribute: (TxFontAttribute with: font1). > > (text startPosition + 7 selectTo: text startPosition + 12) > applyAttribute: (TxForeColorAttribute with: Color green); > applyAttribute: (TxFontAttribute with: font2). > > (text startPosition + 12 selectTo: text startPosition + 18) > applyAttribute: (TxForeColorAttribute with: Color blue); > applyAttribute: (TxFontAttribute with: font3). > > TxTextEditorMorph openInWindowWithText: text > > > > > > >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Tx-Bold-Text-tp4822964p4822987.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

April 29, 2015

Re: [Pharo-dev] Tx: Bold Text

by Nicolai Hess

2015-04-29 18:04 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Nicolai Hess wrote > > Assign the proper Attribute? > > Well AFAICT there is no bold attribute, Ah yes, I mix up this with TextMorph and addAttribute:TextEmphasis.... > but I tried setting the font to bold > via "(LogicalFont familyName: 'Tahoma' pointSize: 9 + i) emphasis: 1; > yourself." but it was rendered the same as before... > > If the font is in the system, this should work. | text font1 font2 font3 string1 | font1 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: TextEmphasis normal emphasisCode. font2 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: TextEmphasis bold emphasisCode. font3 := (LogicalFont familyName: 'Tahoma' pointSize: 25) emphasis: TextEmphasis italic emphasisCode. string1 := 'Normal Bold Italic '. text := TxModel new. text at: text startPosition insert: string1. (text startPosition selectTo: text startPosition + 7) applyAttribute: (TxForeColorAttribute with: Color red); applyAttribute: (TxFontAttribute with: font1). (text startPosition + 7 selectTo: text startPosition + 12) applyAttribute: (TxForeColorAttribute with: Color green); applyAttribute: (TxFontAttribute with: font2). (text startPosition + 12 selectTo: text startPosition + 18) applyAttribute: (TxForeColorAttribute with: Color blue); applyAttribute: (TxFontAttribute with: font3). TxTextEditorMorph openInWindowWithText: text > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Tx-Bold-Text-tp4822964p4822987.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 29, 2015

Re: [Pharo-dev] TimeStamp deprecation and related frameworks (GLORP, Grease, Magritte, Seaside...)

by Esteban A. Maringolo

2015-04-29 12:49 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> On 29 Apr 2015, at 17:39, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> In the case of GLORP, which I'm updating too, TimeStamp use is more >> extended, because it's also a datatype used to map table columns, but >> using no timezone offset. I guess if we move to DateAndTime we should >> preserve that behavior in order to not break anything. > I don't understand this last point, could you elaborate ? > As far as I see it, there is nothing TimeStamp did that DateAndTime cannot do. Me neither. But I simply don't wan't to break anything. :) >> ps: I'm so tempted to fork from the GLORP package, rename as something >> else (PLORM?) and refactor it mercilessly. > That is something else ;-) :)

April 29, 2015

Re: [Pharo-dev] [Pharo5] Testers needed: AST based syntax highlighting

by Marcus Denker

>> >> >> In (old) Workspace editing this >> >> 'a(b)'. >> "ab". >> >> by just removing the first ' or " >> -> UndefinedObject(Object)>>doesNotUnderstand: #doSemanticAnalysis >> > I think I fixed itâ¦ (will add a slice) > https://pharo.fogbugz.com/f/cases/15443/AST-based-highlighter-DNU-sometimes <https://pharo.fogbugz.com/f/cases/15443/AST-based-highlighter-DNU-sometimes> Marcus

April 29, 2015

Re: [Pharo-dev] Pharo 50 has old Rubric Repo

by Sean P. DeNigris

Tudor Girba-2 wrote > Sure. Andrei only explained why it did not happen yet. :) I see it's been added. Any reason not to remove Alain's repo from the list to avoid confusion? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-50-has-old-Rubric-Repo-tp4822586p4823004.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 29, 2015

Re: [Pharo-dev] Rectangle Center

by Nicolas Cellier

2015-04-29 18:50 GMT+02:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > > > On 29/04/15 15:18, Sean P. DeNigris wrote: > > Natalia Tymchuk wrote > >> Should it really be like that? > > > > The problem is that you can't have half-a-pixel if a dimension is odd > > > > For these situations, I would use the method #floor or #rounded of the > class Point, or create the method #roundedCenter, as Natalia suggested. > > Currently, the name of the class and the method communicate the wrong > behavior. > > Tommaso > > Rectangle was and still is a primitive type known to low level graphics operations. It's just that it pre-empts a word that is more generic than the implementation ;) You can't even rotate a rectangle... It's just a clipping or viewport rectangle having same orientation as a rectangular target canvas (image, bitmap, screen or other device). Depending on what you are after, it's maybe not the right abstraction... That does not mean that Rectangle can't be changed. That means that it must be carefully changed as long as it is used for the low level stuff... ...or it must be split. Maybe it's where namespaces might help. Nicolas > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Rectangle-Center-tp4822883p4822891.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > >

April 29, 2015