In the bug report is a patch.
http://bugs.freepascal.org/view.php?id=16682
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist - fpc-devel@lists.free
I don't think this is a bug. It's usual that Right/Bottom denotes one
pixel off intended rectangle. Think in terms of floating point: 1 =
1.0 means left side of the pixel. And 1.5 would mean center of pixel.
So in THAT case, difference between left-most and right-most pixels
are 2.5-1.5=1.0. On the
On Wed, 09 Jun 2010 09:26:10 +0200
Graeme Geldenhuys wrote:
>
> In the bug report is a patch.
>
>
> http://bugs.freepascal.org/view.php?id=16682
Rect and Bounds work mathematically.
A pixel has a size of 1x1 and Left, Top is the left, top edge of a
pixel.
Mattias
_
On 6/9/2010 9:26 AM, Graeme Geldenhuys wrote:
In the bug report is a patch.
http://bugs.freepascal.org/view.php?id=16682
Regards,
- Graeme -
It's not a bug. Plz withdraw (0..9)(1..10?)
___
fpc-devel maillist - fpc-devel@lists.free
Op 2010-06-09 09:40, Mattias Gaertner het geskryf:
>
> Rect and Bounds work mathematically.
> A pixel has a size of 1x1 and Left, Top is the left, top edge of a
> pixel.
That is not mentioned anywhere in the docs so how are we supposed to know
what Bounds() is supposed to be used for. Also 99% of
On Wed, 09 Jun 2010 09:59:22 +0200
Graeme Geldenhuys wrote:
> Op 2010-06-09 09:40, Mattias Gaertner het geskryf:
> >
> > Rect and Bounds work mathematically.
> > A pixel has a size of 1x1 and Left, Top is the left, top edge of a
> > pixel.
>
> That is not mentioned anywhere in the docs so how a
Op 2010-06-09 10:24, Mattias Gaertner het geskryf:
>
> Bounds is used a lot in Delphi and LCL applications.
>
So for "delphi compatibility" we now need to duplicate Delphi bugs in FPC
too? FPC <> DELPHI.
This is just crazy! Where are we going to draw the line with Delphi
compatibility and actua
Graeme Geldenhuys schrieb:
> Op 2010-06-09 10:24, Mattias Gaertner het geskryf:
>> Bounds is used a lot in Delphi and LCL applications.
>>
>
> So for "delphi compatibility" we now need to duplicate Delphi bugs in FPC
> too? FPC <> DELPHI.
As explained, it is not a bug. Classes does not aim on gui
Op 2010-06-09 10:46, Florian Klaempfl het geskryf:
>
> As explained, it is not a bug. Classes does not aim on gui only
> development so the behaviour is logical.
I see Jonas marked it as a Documentation bug so that it's usage can clearly
be defined for math use only. I still think it should then
Graeme Geldenhuys schrieb:
> Op 2010-06-09 10:46, Florian Klaempfl het geskryf:
>> As explained, it is not a bug. Classes does not aim on gui only
>> development so the behaviour is logical.
>
> I see Jonas marked it as a Documentation bug so that it's usage can clearly
> be defined for math use o
Op 2010-06-09 11:02, Florian Klaempfl het geskryf:
> interpretation of bounds, the current behaviour is perfectly valid for
> any other uses.
Not as I see it, and described in the bug report. Think of the pixel
screen/grid like the grid of a spreadsheet (as as a magnified look of the
top corner of
Graeme Geldenhuys schrieb:
> Op 2010-06-09 11:02, Florian Klaempfl het geskryf:
>> interpretation of bounds, the current behaviour is perfectly valid for
>> any other uses.
>
> Not as I see it,
Pixel usage.
___
fpc-devel maillist - fpc-devel@lists.fr
On Wed, Jun 9, 2010 at 11:30, Graeme Geldenhuys wrote:
> Op 2010-06-09 11:02, Florian Klaempfl het geskryf:
>> interpretation of bounds, the current behaviour is perfectly valid for
>> any other uses.
>
> Not as I see it, and described in the bug report. Think of the pixel
> screen/grid like the g
Op 2010-06-09 12:08, Aleksa Todorovic het geskryf:
> point of view regarding coordinates. You assume that integer
> coordinates represent center of pixel, but they actually represent
> top-left corner of pixel. In other words, think of coordinate 0 as
> 0.0, not 0.5 and the math will work perfectly
On Wed, Jun 9, 2010 at 12:22, Graeme Geldenhuys wrote:
> Op 2010-06-09 12:08, Aleksa Todorovic het geskryf:
>> point of view regarding coordinates. You assume that integer
>> coordinates represent center of pixel, but they actually represent
>> top-left corner of pixel. In other words, think of co
Zitat von Aleksa Todorovic :
On Wed, Jun 9, 2010 at 11:30, Graeme Geldenhuys
wrote:
Op 2010-06-09 11:02, Florian Klaempfl het geskryf:
interpretation of bounds, the current behaviour is perfectly valid for
any other uses.
Not as I see it, and described in the bug report. Think of the pixel
On Wednesday 09 June 2010 11:30:21 Graeme Geldenhuys wrote:
> Op 2010-06-09 11:02, Florian Klaempfl het geskryf:
> > interpretation of bounds, the current behaviour is perfectly valid for
> > any other uses.
>
> Not as I see it, and described in the bug report. Think of the pixel
> screen/grid like
Op 2010-06-09 14:32, Martin Schreiber het geskryf:
> TRect has been defined in order to communicate
> rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...):
And X11 (XLib) was intelligent enough to foresee the ambiguity and use X,
Y, Width, Height in all drawing API's instead of Top,
On 2010-06-09 16:31, Graeme Geldenhuys wrote:
But then somebody would throw the "not delphi compatible" card at me.
I seem to be stuck in a endless loop: I find a issue, report it,
get told it's not delphi compatible, everybody ignores issue. Repeat.
I don't get it.
I can see that what Gra
2010/6/9 Adem :
> On 2010-06-09 16:31, Graeme Geldenhuys wrote:
>
>> But then somebody would throw the "not delphi compatible" card at me.
>> I seem to be stuck in a endless loop: I find a issue, report it,
>> get told it's not delphi compatible, everybody ignores issue. Repeat.
>>
>
> I don't get
In our previous episode, Graeme Geldenhuys said:
> > Because of the ambiguity MSEgui uses solely the "rectty" type:
>
> And fpGUI has TfpgRect since the start. I just seem to think it's rather
> stupid that everybody needs to implement their own types, functions,
> classes because the default beh
On 09 Jun 2010, at 15:57, Adem wrote:
Why not keep the 'Delphi compatible' arguement to 'Delphi mode', but
allow it in FPC native mode?
In this particular case: unit doesn't have a Delphi and FPC mode. A
unit always contains the same functionality.
In general: please take that discussion
Op 2010-06-09 16:06, Henry Vermaak het geskryf:
>
> * Because it would be idiotic to change something based on a point of
> view of one person.
It's not just one person. Lets just take the Rectangle type/structure.
* Delphi has it's own (based on Windows TRect - how original)
* fpGUI has it's ow
Zitat von Graeme Geldenhuys :
Op 2010-06-09 16:06, Henry Vermaak het geskryf:
* Because it would be idiotic to change something based on a point of
view of one person.
It's not just one person. Lets just take the Rectangle type/structure.
* Delphi has it's own (based on Windows TRect - how
On 2010-06-09 17:52, Graeme Geldenhuys wrote:
Op 2010-06-09 16:06, Henry Vermaak het geskryf:
* Because it would be idiotic to change something based on a point of
view of one person.
It's not just one person. Lets just take the Rectangle type/structure.
Graeme,
While I cannot a
On Wednesday 09 June 2010 15:31:27 Graeme Geldenhuys wrote:
> Op 2010-06-09 14:32, Martin Schreiber het geskryf:
> > TRect has been defined in order to communicate
> > rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...):
>
> And X11 (XLib) was intelligent enough to foresee the ambigu
On 09/06/2010, Adem wrote:
> Couldn't you all 2-3 project leaders (of fpgui, kol, msegui) agree on a
> common library (that you build gradually) as part of FPC?
Based on my experience over the last 6 months alone, I might just
investigate this a bit more. But one thing is for sure... If I go down
Graeme Geldenhuys schrieb:
> On 09/06/2010, Adem wrote:
>> Couldn't you all 2-3 project leaders (of fpgui, kol, msegui) agree on a
>> common library (that you build gradually) as part of FPC?
>
> Based on my experience over the last 6 months alone, I might just
> investigate this a bit more. But o
On 6/9/2010 5:07 PM, Mattias Gärtner wrote:
* KOL probably has it's own too
no
Yup, no.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/06/2010, Florian Klaempfl wrote:
>
> Go ahead, we'll talk in 10 years and we'll see what you'll do if a
But you forget, I'll be the only one using the new RTL and fpGUI
remember. ;-) You really make it sound like you are the only person
that has ever maintained a project for 10+ years - we
On 09 Jun 2010, at 22:38, Graeme Geldenhuys wrote:
> Just because FPC had radical changes between v1 & v2 and still doesn't
> know what it wants to be, other than a Delphi clone (yet Delphi
> already exists - we don't need two of them), that doesn't mean every
> other project will have the same p
Graeme Geldenhuys schrieb:
Bounds is used a lot in Delphi and LCL applications.
So for "delphi compatibility" we now need to duplicate Delphi bugs in FPC
too? FPC <> DELPHI.
It's not a bug, it's a commonly accepted graphics model.
The only thing I'm missing is a distinction between rectang
32 matches
Mail list logo
