Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 rectangles in origin-extent and in two-point (TL, BR) representation. IMO two distinct types should be available for these, with according conversion procedures. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 other hand, width of rectangle is still 2.0 - one between 1.0 and 2.0, and the other between 2.0 and 3.0. Huh, too much text for such simple math :-) On Wed, Jun 9, 2010 at 09:26, Graeme Geldenhuys graemeg.li...@gmail.com wrote: 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-de...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Aleksa Todorovic - Lead Programmer Eipix Entertainment www eipix com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
On Wed, 09 Jun 2010 09:26:10 +0200 Graeme Geldenhuys graemeg.li...@gmail.com 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 cases where TRect is used, it's in a graphical aspect. ClientRect, WindowRect, GetClientBounds, TextRect... and a million others. All related to graphics (and pixels on a screen) Maybe we then need a GraphicalBounds() and MathBounds() to distinguish between the two, and remove Bounds() completely. Bounds() on it's own is just to vague, and more often than not, its calculation of Right and Bottom is incorrect based on (graphical) usage. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
On Wed, 09 Jun 2010 09:59:22 +0200 Graeme Geldenhuys graemeg.li...@gmail.com 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 are we supposed to know what Bounds() is supposed to be used for. I agree, such basics should be explained in a tutorial and the docs of classes and types. Also 99% of cases where TRect is used, it's in a graphical aspect. ClientRect, WindowRect, GetClientBounds, TextRect... and a million others. All related to graphics (and pixels on a screen) Yes, and afaik most use mathematical width/height for the simple reason they add up (commutative and associative). Maybe we then need a GraphicalBounds() and MathBounds() to distinguish between the two, and remove Bounds() completely. Bounds() on it's own is just to vague, and more often than not, its calculation of Right and Bottom is incorrect based on (graphical) usage. Bounds is used a lot in Delphi and LCL applications. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 actually implement something in FPC that is correct, not vague and on ALL platforms not just freaking Windows (+ Delphi). Yes Delphi is important (I get that), but so is FPC on other platforms. FPC is not Delphi for Linux, or Delphi for Mac etc. That's Embarcadero's domain. In the last 6 months I found so many bugs in FPC, but every single one was shot down and said: It's Delphi compatible. End of discussion! Well, Delphi doesn't exist on Linux, FreeBSD, Solaris, WinCE, Embedded Linux, Android, iPhone, Mac, Haiku etc.. All platforms FPC supports too. I give up... Lets hope Embarcadero brings out an excellent Delphi x-platform compiler, then I can switch to Delphi and be done with it. Clearly that's the goal of FPC - drive developers back to Delphi. You guys should charge Embarcadero for your services. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 only development so the behaviour is logical. If you don't like it, create a fpGuiBounds function. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 be moved to the Math uni, but that is not delphi compatible - though it would be a lot less ambiguous there. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 only. I still think it should then be moved to the Math uni, Why? I could imagine to add a PixelBounds function to a newly PixelGraphics unit. Only pixel graphics might need a different interpretation of bounds, the current behaviour is perfectly valid for any other uses. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 your screen) 0 1 +---+---+--- 0 | x | | +-+-+---+--- 1 | | | +-+-+---+--- 2 | | | +-+-+---+--- x is at (0,0). A pixel is always 1x1, you don't get smaller (we are not using sub-pixels like on LCD screens, because they don't apply to all screens). So with that example, Width = 1 pixel and Height = 1 pixel. In the case of Classes.Bounds() the Right and Bottom values are (1,1) which looking at the above image will be wrong, the pixel only covers one block, so in a screen/pixel environment, Right, Bottom is also (0,0), the same as Top/Left. 0 1 +---+---+--- 0 | x | x | +-+-+---+--- 1 | x | x | +-+-+---+--- 2 | | | +-+-+---+--- In this example we have a rectangle. Top/Left = (0,0) and Bottom/Right = (1,1). This means Width = 2 pixels and Height = 2 pixels. Clearly visible in the image above. But if we call Classes.Bounds(0,0,2,2) it reports Bottom/Right as (2,2) which is wrong (again looking at the image above as reference). This is my point. Bounds() cannot be used in this case in a graphical environment. The reason I don't use a grid layout as below (as Mattias hinted at), is because if the mouse is over the x, the OS (graphics system) reports its position as (0,0). You don't have to have the mouse pointer over the cross-section lines (0,0) as indicated in the image below. The whole square containing the x is referenced as (0,0), hence my grid layout as show in the images above. The same grid layout as used in TStringGrid or a spreadsheet etc. 0 1 0 +---+---+--- | x | | 1 +-+-+---+--- | | | 2 +-+-+---+--- | | | 3 +-+-+---+--- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
On Wed, Jun 9, 2010 at 11:30, Graeme Geldenhuys graemeg.li...@gmail.com 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 grid of a spreadsheet (as as a magnified look of the top corner of your screen) 0 1 +---+---+--- 0 | x | | +-+-+---+--- 1 | | | +-+-+---+--- 2 | | | +-+-+---+--- x is at (0,0). A pixel is always 1x1, you don't get smaller (we are not using sub-pixels like on LCD screens, because they don't apply to all screens). So with that example, Width = 1 pixel and Height = 1 pixel. In the case of Classes.Bounds() the Right and Bottom values are (1,1) which looking at the above image will be wrong, the pixel only covers one block, so in a screen/pixel environment, Right, Bottom is also (0,0), the same as Top/Left. 0 1 +---+---+--- 0 | x | x | +-+-+---+--- 1 | x | x | +-+-+---+--- 2 | | | +-+-+---+--- In this example we have a rectangle. Top/Left = (0,0) and Bottom/Right = (1,1). This means Width = 2 pixels and Height = 2 pixels. Clearly visible in the image above. But if we call Classes.Bounds(0,0,2,2) it reports Bottom/Right as (2,2) which is wrong (again looking at the image above as reference). This is my point. Bounds() cannot be used in this case in a graphical environment. Actually, everything works fine here :-) You just have to change your 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 fine :-) The reason I don't use a grid layout as below (as Mattias hinted at), is because if the mouse is over the x, the OS (graphics system) reports its position as (0,0). You don't have to have the mouse pointer over the cross-section lines (0,0) as indicated in the image below. The whole square containing the x is referenced as (0,0), hence my grid layout as show in the images above. The same grid layout as used in TStringGrid or a spreadsheet etc. 0 1 0 +---+---+--- | x | | 1 +-+-+---+--- | | | 2 +-+-+---+--- | | | 3 +-+-+---+--- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-de...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Aleksa Todorovic - Lead Programmer Eipix Entertainment www eipix com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 fine :-) An if you read the rest of my reply, you would have seen the reason why I use that coordinate system, instead of the intersecting lines (and rather like a spreadsheet or TStringGrid). The way the OS graphics system works (at least for GDI X11) - confirms my thinking. If you have a 1x1 pixel at (0,0) on the screen, the mouse cursor can be anywhere inside the 1x1 rectangle (rectangle with the x in image below), and the OS reports it as location (0,0). My coordinate system reflects this behaviour. If only the top/left corner (intersecting lines) was (0,0), then my mouse cursor would also have to be in the top/left corner before the OS reports (0,0) - which it doesn't. 0 1 +---+---+--- 0 | x | | +-+-+---+--- 1 | | | +-+-+---+--- 2 | | | +-+-+---+--- Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
On Wed, Jun 9, 2010 at 12:22, Graeme Geldenhuys graemeg.li...@gmail.com 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 coordinate 0 as 0.0, not 0.5 and the math will work perfectly fine :-) An if you read the rest of my reply, you would have seen the reason why I use that coordinate system, instead of the intersecting lines (and rather like a spreadsheet or TStringGrid). The way the OS graphics system works (at least for GDI X11) - confirms my thinking. If you have a 1x1 pixel at (0,0) on the screen, the mouse cursor can be anywhere inside the 1x1 rectangle (rectangle with the x in image below), and the OS reports it as location (0,0). My coordinate system reflects this behaviour. If only the top/left corner (intersecting lines) was (0,0), then my mouse cursor would also have to be in the top/left corner before the OS reports (0,0) - which it doesn't. 0 1 +---+---+--- 0 | x | | +-+-+---+--- 1 | | | +-+-+---+--- 2 | | | +-+-+---+--- Let's imagine (it doesn't have to be true) that OS calculates mouse coordinates as floating point values. In that case your mouse coordinates are in the range (0.0 - 0.99), but OS reports it as (0, 0), which means that OS internally calls Trunc. So, you can think of coordinates as Trunc-ed (not Round-ed!) version of real coordinates. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-de...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- Aleksa Todorovic - Lead Programmer Eipix Entertainment www eipix com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
Zitat von Aleksa Todorovic alexi...@gmail.com: On Wed, Jun 9, 2010 at 11:30, Graeme Geldenhuys graemeg.li...@gmail.com 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 grid of a spreadsheet (as as a magnified look of the top corner of your screen) 0 1 +---+---+--- 0 | x | | +-+-+---+--- 1 | | | +-+-+---+--- 2 | | | +-+-+---+--- x is at (0,0). A pixel is always 1x1, you don't get smaller (we are not using sub-pixels like on LCD screens, because they don't apply to all screens). It's correct that a pixel is an area, usually of size 1x1. So when you say it is at 0,0, then you are really saying: the left,top corner of the pixel is at 0,0 and the right, bottom corner is at 1,1. With the Bounds function: Bounds(0,0,1,1) Math: Right-Left=Width Graeme: Right-Left=Width-1 For example: Let's say you have a position 3. The math says it is the left edge of pixel 3 (usually the fourth pixel). Graeme says: If it is a Left, then it is the left edge of pixel 3, if it is a Right then it is the right edge of pixel 3. Graeme's definition is useful for drawing a pixel based rectangle (with line width of 1). When computing with coordinates the math definition is easier as you don't have to know if it is a left or right. [...] 0 1 +---+---+--- 0 | x | x | +-+-+---+--- 1 | x | x | +-+-+---+--- 2 | | | +-+-+---+--- In this example we have a rectangle. Top/Left = (0,0) and Bottom/Right = (1,1). This means Width = 2 pixels and Height = 2 pixels. Clearly visible in the image above. That's only correct for a line width of 1. The rectangle has a line width of 1 pixel, 0.5 pixel around the four x. This means the rectangle has Width=1 and Height=1, but including the thickness of the line the total rectangle has Width=2 and Height=2. The difference can be seen when using libraries that supports sub pixel rendering like aggpas. But if we call Classes.Bounds(0,0,2,2) it reports Bottom/Right as (2,2) which is wrong (again looking at the image above as reference). This is my point. Bounds() cannot be used in this case in a graphical environment. Yes, it can. If you want the rectangle including the line width of 1, you must add 1. If you use a line width of 5 you must add 5. Maybe you want a Bounds function like this: function RectangleHull(Left, Top, Width, Height: integer; LineWidth: integer = 1): TRect; Actually, everything works fine here :-) You just have to change your 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 fine :-) The math works with 0.0, 0.5 and 0.9. But if you don't use sub pixel rendering you won't see the difference. [...] Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 the grid of a spreadsheet (as as a magnified look of the top corner of your screen) [...] I think you are wrong, TRect has been defined in order to communicate rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...): http://msdn.microsoft.com/en-us/library/aa932720.aspx When filling the specified rectangle, FillRect does not include the rectangle's right and bottom sides. GDI fills a rectangle up to, but not including, the right column and bottom row, regardless of the current mapping mode. http://msdn.microsoft.com/en-us/library/aa932835(v=MSDN.10).aspx The region will be exclusive of the bottom and right edges. Because of the ambiguity MSEgui uses solely the rectty type: rectty = record case integer of 0: (x,y,cx,cy: integer); 1: (pos: pointty; size: sizety); end; Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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,Left,Right,Bottom. We all know Microsoft is just as capable as everybody else to create sh*t software or APIs. Now I can argue once again that FPC is supposed to be a x-platform product, hence it should not JUST follow Microsoft to every single word, but also take other platforms (8+ at last count) into consideration. 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 should also point out that you can (and least I know this is true in Xlib) adjust the pen cap attributes, which changes the behaviour you mentioned. At which point it can include the Right/Bottom pixels in rectangle, line drawing etc. 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 behaviour of FPC is idiotic and doesn't apply to non-Windows platforms. From the start my goal with fpGUI was to use as much as possible of what is includes by FPC as default (so I don't have to re-invent the wheel) - this means functions, classes, packages etc. But lately I think that is simply a pipe-dream, because everything I want to do or change, seems to be not delphi compatible and such changes are NOT allowed in FPC. TfpgRect = object // not class for static allocations Top: TfpgCoord; Left: TfpgCoord; Width: TfpgCoord; Height: TfpgCoord; procedure SetRect(aleft, atop, awidth, aheight: TfpgCoord); function Bottom: TfpgCoord; function Right: TfpgCoord; procedure SetBottom(Value: TfpgCoord); procedure SetRight(Value: TfpgCoord); end; So maybe Marco's idea of a new NOT delphi compatible RTL is not so crazy after all. At least we will have the freedom of implementing better designs and something that works consistently across all FPC supported platforms. The red-tape will be so much less, but unfortunately the work involved to create a new RTL will be huge. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 Graeme is pointing out does have merit. Why reject it altogether with an arguement like it's not Delphi compatible? Doesn't FPC have a 'Delphi Compatible' mode, as well as a native mode? Why not keep the 'Delphi compatible' arguement to 'Delphi mode', but allow it in FPC native mode? -- Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
2010/6/9 Adem listmem...@letterboxes.org: 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 Graeme is pointing out does have merit. Why reject it altogether with an arguement like it's not Delphi compatible? * Because it would be idiotic to change something based on a point of view of one person. * It would break everyone else's applications. Doesn't FPC have a 'Delphi Compatible' mode, as well as a native mode? Afaik that's only for language features (I hope). Why not keep the 'Delphi compatible' arguement to 'Delphi mode', but allow it in FPC native mode? Why don't we introduce a GraphicalBounds function? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 behaviour of FPC is idiotic and doesn't apply to non-Windows platforms. Note that this thread confuses two issues: 1 the fact that the default units reflect delphi because of the compability 2 the fact that the non-delphi projects (kol,msegui, fpgui, anybody have any more?) don't pool their efforts to have common workarounds in a set of units. The (1) is a namespace problem, and not easily solved. (2) is way easier fixable since it features additional units, if it is stable enough in say an year, we can enter it it as an FPC package even. I know (2) doesn't fix everything, like component streaming (which is fixable but only by duplicating classes), but at least it would be a start, and more constructive than the current flamefest. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 to the fpc-other list. We already drowned this list with such a discussion last week. Thanks, Jonas FPC mailing lists moderator ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 own: TfpgRect * MSEgui has it's own: rectty * AggPas has it's own: rect_ptr, rect_d, rect_i * KOL probably has it's own too * ... pretty sure there are more Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
Zitat von Graeme Geldenhuys graemeg.li...@gmail.com: 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) left,top,right,bottom * fpGUI has it's own: TfpgRect tell us * MSEgui has it's own: rectty left,top,width,height * AggPas has it's own: rect_ptr, rect_d, rect_i doubles and C int type. Aggpas is a C port. C people are used to reinvent the wheel. * KOL probably has it's own too no * ... pretty sure there are more As far as I can see, every one of the above has a good reason to use their own type. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 agree with Henry that things cannot change based on a point of view of one person [of course, they can/should --provided that point of view is correct], I do see that such a change can/might play havoc with people's codebases hence not very desirable. That brings us to Marco's suggestion: It does sound like the best of both worlds. 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? I can also that it would take far less time to convince other project leaders on what should go into that lib than it's taking now. Given that all these projects have been going on for so long, it may not even have to be called beta. -- Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 ambiguity and use X, Y, Width, Height in all drawing API's instead of Top,Left,Right,Bottom. We all know Microsoft is just as capable as everybody else to create sh*t software or APIs. Agreed. ;-) Now I can argue once again that FPC is supposed to be a x-platform product, hence it should not JUST follow Microsoft to every single word, but also take other platforms (8+ at last count) into consideration. 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 think the current Bounds() behaviour is stupid. Because of the way it works the definition is the same for integer and float coordinates. Qt uses your approach in QRect because of historical reasons: http://doc.qt.nokia.com/4.6/qrect.html#bottom and it seems they don't think that it is correct: int QRect::bottom () const Returns the y-coordinate of the rectangle's bottom edge. Note that for historical reasons this function returns top() + height() - 1; use y() + height() to retrieve the true y-coordinate. and There is a third constructor that creates a QRect using the top-left and bottom-right coordinates, but we recommend that you avoid using it. The rationale is that for historical reasons the values returned by the bottom() and right() functions deviate from the true bottom-right corner of the rectangle. I should also point out that you can (and least I know this is true in Xlib) adjust the pen cap attributes, which changes the behaviour you mentioned. At which point it can include the Right/Bottom pixels in rectangle, line drawing etc. This applies for linendings only. XFillRectangle() with width or height = 0 paints nothing AFAIK. So maybe Marco's idea of a new NOT delphi compatible RTL is not so crazy after all. At least we will have the freedom of implementing better designs and something that works consistently across all FPC supported platforms. The red-tape will be so much less, but unfortunately the work involved to create a new RTL will be huge. I am not sure if it is possible to design an ideal RTL which fulfils all requirements, they are too different. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 that route, it will be open source of course, but I doubt I'll submit it to the FPC project (for a good few years at least). I'll rather keep it as a separate package (similar to FCL). The last thing I want is yet more red tape. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 one thing is for sure... If I go down that route, it will be open source of course, but I doubt I'll submit it to the FPC project (for a good few years at least). I'll rather keep it as a separate package (similar to FCL). The last thing I want is yet more red tape. Go ahead, we'll talk in 10 years and we'll see what you'll do if a single user starts to cry on your mailing list to break the code of thousands of your users only because something doesn't fit according to his logic. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 - well you're not! 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 pitfalls of FPC. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
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 pitfalls of FPC. And this exchange makes for another thread that's now moderated. Jonas FPC mailing lists admin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
