Re: RFC: Sane rectangle class

2020-03-24 Thread Thorsten Behrens
Luboš Luňák wrote: > I'm confused. I wrote that I find the API bad and that it would probably > require writing it again from scratch. You call that tweaking? > Ain't that much code, so yeah, tweaks.. > How is this bike-shedding? Discussing the code will get much harder > without handling the

Re: RFC: Sane rectangle class

2020-03-24 Thread Luboš Luňák
On Monday 23 of March 2020, Thorsten Behrens wrote: > Luboš Luňák wrote: > > Replacing one error-prone API with another error-prone API doesn't solve > > anything. > > True. But the basegfx classes are reasonably easy to tweak (and > B2IRect has only few clients). I'm confused. I wrote that I

Re: RFC: Sane rectangle class

2020-03-23 Thread Thorsten Behrens
Luboš Luňák wrote: > Replacing one error-prone API with another error-prone API doesn't solve > anything. > True. But the basegfx classes are reasonably easy to tweak (and B2IRect has only few clients). Perhaps best to let code speak? Happy to continue the bike-shedding on gerrit (and perhaps

Re: RFC: Sane rectangle class

2020-03-23 Thread Thorsten Behrens
Luboš Luňák wrote: > [...] simpler to just write the class from scratch rather than try > to be too smart and share the code with tools::Rectangle, but if it > would be in the same header and had pretty much the same API, then > for most practical purposes it would be still part of that >

Re: RFC: Sane rectangle class

2020-03-23 Thread Noel Grandin
On Mon, 23 Mar 2020 at 17:12, Luboš Luňák wrote: > > I see the problem not in tools::Rectangle itself, but in the fact, that > > it uses integer and not double. Using double makes width = right - left > > in all cases > > and would solve accuracy problems in manipulating shapes. > > It would be

Re: RFC: Sane rectangle class

2020-03-23 Thread Luboš Luňák
On Friday 20 of March 2020, Regina Henschel wrote: > Luboš Luňák schrieb am 19-Mar-20 um 16:13: > > Hello, > > > > yes, this is about the tools::Rectangle nightmare of an API (in case > > you don't know, it's this [1] ). I'm hunting an off-by-one error > > somewhere in VCL, and it's hard to

Re: RFC: Sane rectangle class

2020-03-23 Thread Luboš Luňák
On Friday 20 of March 2020, Tomaž Vajngerl wrote: > I fear a bit introducing a new implementation as that will just mean one > more implementation that we will have to deal long run, but I don't think > it would make things much worse as they are now - at elast we will know > what was audited to

Re: RFC: Sane rectangle class

2020-03-23 Thread Luboš Luňák
On Friday 20 of March 2020, Thorsten Behrens wrote: > Luboš Luňák wrote: > > > One question: any reason not to tweak the basegfx classes to fit this > > > model? > > > > Looking at those classes, I think their API serves some other > > purpose than "simple point/size/rectangle", so the closest to

Re: RFC: Sane rectangle class

2020-03-20 Thread Tomaž Vajngerl
Hi, On Fri, Mar 20, 2020 at 11:54 PM Regina Henschel wrote: > Hi, > > The problem for huge values is not Writer but Calc. For example, make a > sheet with row height 10cm on all rows. Insert a shape in A2000 and look > at the position information in the status bar. (Shapes are anchored to >

Re: RFC: Sane rectangle class

2020-03-20 Thread Regina Henschel
Hi, Tomaž Vajngerl schrieb am 20-Mar-20 um 18:13: Hi, Do you know a specific case where that actually matters? My personal position on integers is "use int, unless you explicitly need something else". We are dealing with 100th-mm or twip units, which can get quite big (in

Re: RFC: Sane rectangle class

2020-03-20 Thread Thorsten Behrens
Hi Regina, *, Regina Henschel wrote: > These off-by-one problems occur earlier than in VCL. For example > changes to maSnapRect when a shape is transformed by shear and > rotation. > Yep. Also c.f. SwRect mentioned earlier. > A new kind of rectangle does not solve the problem, that you have to >

Re: RFC: Sane rectangle class

2020-03-20 Thread Regina Henschel
Hi Luboš, Luboš Luňák schrieb am 19-Mar-20 um 16:13: Hello, yes, this is about the tools::Rectangle nightmare of an API (in case you don't know, it's this [1] ). I'm hunting an off-by-one error somewhere in VCL, and it's hard to find it when I can't even tell which parts of the code are

Re: RFC: Sane rectangle class

2020-03-20 Thread Jan-Marek Glogowski
FWIW there is also canvas/source/tools/surfacerect.hxx, which might be the lowest hanging fruit to get rid of, and which I found when fixing tdf#40534 :-) If you replace this as a starter, we would at least not have the "just and additional standard" situation and keep our Rectangle type count

Re: RFC: Sane rectangle class

2020-03-20 Thread Tomaž Vajngerl
Hi, Do you know a specific case where that actually matters? My personal > position > on integers is "use int, unless you explicitly need something else". > > We are dealing with 100th-mm or twip units, which can get quite big (in writer we are always referencing relative from page 1 AFAIK) and

Re: RFC: Sane rectangle class

2020-03-20 Thread Tomaž Vajngerl
Hi, On Thu, Mar 19, 2020 at 4:14 PM Luboš Luňák wrote: > > Hello, > > yes, this is about the tools::Rectangle nightmare of an API (in case you > don't know, it's this [1] ). I'm hunting an off-by-one error somewhere in > VCL, and it's hard to find it when I can't even tell which parts of the

Re: RFC: Sane rectangle class

2020-03-20 Thread Thorsten Behrens
Luboš Luňák wrote: > > One question: any reason not to tweak the basegfx classes to fit this > > model? > > Looking at those classes, I think their API serves some other > purpose than "simple point/size/rectangle", so the closest to > tweaking them I see is wrapping them in a completely new

Re: RFC: Sane rectangle class

2020-03-20 Thread Noel Grandin
On 2020/03/20 2:12 pm, Luboš Luňák wrote: With one extra wrinkle: the current tools::Rectangle uses long, and lots of places that work with tools::Rectangle also use long, which is particularly pernicious because long is a different bit-size on Windows and Linux. Do you know a specific

Re: RFC: Sane rectangle class

2020-03-20 Thread Luboš Luňák
On Thursday 19 of March 2020, Thorsten Behrens wrote: > Hey Luboš, > > Luboš Luňák wrote: > > So, yeah, I'm proposing a new standard Rectangle class (and I know > > xkcd, and I'm still serious). My idea is roughly that there will be > > some tools::NewRectangle (or whatever usable name), it will

Re: RFC: Sane rectangle class

2020-03-20 Thread Luboš Luňák
On Thursday 19 of March 2020, Noel Grandin wrote: > On Thu, 19 Mar 2020 at 17:14, Luboš Luňák wrote: > > - internal representation will be whatever sane thing will work, e.g. > > x,y,width,height , and it won't matter for the API > > - empty rectangle is simply width == 0 || height == 0 > > +1 on

Re: RFC: Sane rectangle class

2020-03-19 Thread Thorsten Behrens
Hey Luboš, Luboš Luňák wrote: > So, yeah, I'm proposing a new standard Rectangle class (and I know > xkcd, and I'm still serious). My idea is roughly that there will be > some tools::NewRectangle (or whatever usable name), it will be more > or less like tools::Rectangle, but it'll make things

Re: RFC: Sane rectangle class

2020-03-19 Thread Noel Grandin
On Thu, 19 Mar 2020 at 17:14, Luboš Luňák wrote: > - internal representation will be whatever sane thing will work, e.g. > x,y,width,height , and it won't matter for the API > - empty rectangle is simply width == 0 || height == 0 > > +1 on this part. FWIW, the Java Rectangle API is pretty much

RFC: Sane rectangle class

2020-03-19 Thread Luboš Luňák
Hello, yes, this is about the tools::Rectangle nightmare of an API (in case you don't know, it's this [1] ). I'm hunting an off-by-one error somewhere in VCL, and it's hard to find it when I can't even tell which parts of the code are right or wrong :(. This has been already discussed a