Hi, Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds when a size is not set for the editor. This has some side-effects, like the text in Spotter not appearing on 64 bit given that some drawing methods from the graphical backend seem to expect 32 bit ranges. We can fix this by introducing #maxVal32 or maybe there could be some range checks in the canvas. Comments? Cheers, Andrei |
why does rubric checks for maxVal at first instance?
> On 29 Mar 2017, at 14:07, Andrei Chis <[hidden email]> wrote: > > Hi, > > Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds when a size is not set for the editor. This has some side-effects, like the text in Spotter not appearing on 64 bit given that some drawing methods from the graphical backend seem to expect 32 bit ranges. We can fix this by introducing #maxVal32 or maybe there could be some range checks in the canvas. Comments? > > Cheers, > Andrei |
In reply to this post by Andrei Chis
Hi Andrei,
> On Mar 29, 2017, at 5:07 AM, Andrei Chis <[hidden email]> wrote: > > Hi, > > Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds when a size is not set for the editor. This has some side-effects, like the text in Spotter not appearing on 64 bit given that some drawing methods from the graphical backend seem to expect 32 bit ranges. We can fix this by introducing #maxVal32 or maybe there could be some range checks in the canvas. Comments? Why not introduce a class variable or a Rubric method that answers a constant? It could be the same as 2^30-1 or something smaller. What is the likely maximum extent of a Rubric drawing surface over the next ten years? > > Cheers, > Andrei |
In reply to this post by EstebanLM
On Wed, Mar 29, 2017 at 2:12 PM, Esteban Lorenzano <[hidden email]> wrote: why does rubric checks for maxVal at first instance? This is the problematic code for Spotter: RubAbstractTextArea>>#drawingBounds ^ (self scrollPane isNil or: [ self wrapped ]) ifTrue: [self innerBounds] ifFalse: [ self innerBounds topLeft extent: SmallInteger maxVal @ SmallInteger maxVal ]
|
looks like he’s trying to get an incredible huge drawing area. I would just extract that to a RubAbstractTextArea class>>#maxExtent class method, and with constant numbers, as Eliot suggested. Esteban
|
+ 1 and push it to Rubric. On Wed, Mar 29, 2017 at 5:10 PM, Esteban Lorenzano <[hidden email]> wrote:
|
In reply to this post by EstebanLM
Added a bug report: https://pharo.fogbugz.com/f/cases/19884/Rubric-should-not-use-SmallInteger-maxVal Indeed changing this in Rubric is the best option. #maxVal is used in more places in Rubric, On Wed, Mar 29, 2017 at 5:10 PM, Esteban Lorenzano <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |