From lazarus at mfriebe.de Fri Jun 2 14:55:24 2023 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 2 Jun 2023 14:55:24 +0200 Subject: [Lazarus] Who uses "caret past EOL"? Message-ID: If you do, do you use it within the range of the "longest line" only? That is, currently caret-past-eol additionally allows you to scroll up to over 1000 columns, even if you don't have any line that long. Do you use that scroll range? From michael at freepascal.org Fri Jun 2 15:07:33 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 2 Jun 2023 15:07:33 +0200 (CEST) Subject: [Lazarus] Who uses "caret past EOL"? In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: > If you do, do you use it within the range of the "longest line" only? What if I want to add a comment at column 60 (think explanation about enumerated value) but the max line length is 40 ? Now I click at col 60 and add the comment. Will this still be possible ? Michael. From lazarus at mfriebe.de Fri Jun 2 15:21:04 2023 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 2 Jun 2023 15:21:04 +0200 Subject: [Lazarus] Who uses "caret past EOL"? In-Reply-To: References: Message-ID: On 02/06/2023 15:07, Michael Van Canneyt via lazarus wrote: > > > On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: > >> If you do, do you use it within the range of the "longest line" only? > > > What if I want to add a comment at column 60 (think explanation about > enumerated value) but the max line length is 40 ? > > Now I click at col 60 and add the comment. Will this still be possible ? Yes, it will. The question is how far should it allow by default? ----------- Background: Currently the scroll always goes to 1024. Except when the longest line is longer, then it goes (on any line) to the max = longest line. But never behind that. In future, if you hold cursor-right, it will go further (like notepad ++, if "virtual space" is enabled). Of course that covers the range for cursor keys. About the range for mouse. The current limit is quite big. But if you really have lines that long => it's not enough. So instead you will (optional) be able to scroll (scrollbar / mouse) up to "longest line" + "width of screen". If your Window shows 85 chars, and your longest line is 20 chars, you can mouse move the caret up to 105 (and right cursor will go behind). Those options are already there in the main branch: - no extra scroll, just cursor keys? (well on shorter lines, the mouse can go up to "longest line", but that is placement, not scroll range) - add one page to longest line - Max(1024, longest line) Currently the last is default. Maybe "add one page" is a better default. Unless, there are use cases that require to place the caret more than "one page" past the end of (the longest) line. Since I don't use "caret past eol" at all, this is hard for me to judge. But my experience is, when ever I think there would be no such use case, there is at least one. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40282 From michael at freepascal.org Fri Jun 2 15:57:53 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 2 Jun 2023 15:57:53 +0200 (CEST) Subject: [Lazarus] Who uses "caret past EOL"? In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: > On 02/06/2023 15:07, Michael Van Canneyt via lazarus wrote: >> >> >> On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: >> >>> If you do, do you use it within the range of the "longest line" only? >> >> >> What if I want to add a comment at column 60 (think explanation about >> enumerated value) but the max line length is 40 ? >> >> Now I click at col 60 and add the comment. Will this still be possible ? > > Yes, it will. > The question is how far should it allow by default? > > ----------- > Background: > Currently the scroll always goes to 1024. Except when the longest line > is longer, then it goes (on any line) to the max = longest line. But > never behind that. > > In future, if you hold cursor-right, it will go further (like notepad > ++, if "virtual space" is enabled). > Of course that covers the range for cursor keys. > > About the range for mouse. The current limit is quite big. But if you > really have lines that long => it's not enough. > So instead you will (optional) be able to scroll (scrollbar / mouse) up > to "longest line" + "width of screen". > If your Window shows 85 chars, and your longest line is 20 chars, you > can mouse move the caret up to 105 (and right cursor will go behind). > > Those options are already there in the main branch: > - no extra scroll, just cursor keys? (well on shorter lines, the mouse > can go up to "longest line", but that is placement, not scroll range) > - add one page to longest line > - Max(1024, longest line) > > Currently the last is default. > Maybe "add one page" is a better default. +1, but as you say, use cases vary :-) Michael. From marc at dommelstein.nl Fri Jun 2 18:07:28 2023 From: marc at dommelstein.nl (Marc Weustink) Date: Fri, 2 Jun 2023 18:07:28 +0200 Subject: [Lazarus] Who uses "caret past EOL"? In-Reply-To: References: Message-ID: <08541957-1036-482b-331e-2000ad50aaac@dommelstein.nl> On 02/06/2023 15:21, Martin Frb via lazarus wrote: > On 02/06/2023 15:07, Michael Van Canneyt via lazarus wrote: >> >> >> On Fri, 2 Jun 2023, Martin Frb via lazarus wrote: >> >>> If you do, do you use it within the range of the "longest line" only? I use it, it was the first thing I enabled when it was available in Lazarus. I seldom use my mouse for text navigation (to slow) but in cases where I like to put my caret on a place using the mouse, it is in the visible area of the screen. When using keyboard navigation it can be outside that area. >> What if I want to add a comment at column 60 (think explanation about >> enumerated value) but the max line length is 40 ? >> >> Now I click at col 60 and add the comment. Will this still be possible ? > > Yes, it will. > The question is how far should it allow by default? > > ----------- > Background: > Currently the scroll always goes to 1024. Except when the longest line > is longer, then it goes (on any line) to the max = longest line. But > never behind that. > > In future, if you hold cursor-right, it will go further (like notepad > ++, if "virtual space" is enabled). > Of course that covers the range for cursor keys. Thats fine with me. Having the scrollbar limited to the max(screenwidht+something, longest line) makes sense. Marc From nc-gaertnma at netcologne.de Fri Jun 2 18:44:07 2023 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 2 Jun 2023 18:44:07 +0200 Subject: [Lazarus] Who uses "caret past EOL"? In-Reply-To: <08541957-1036-482b-331e-2000ad50aaac@dommelstein.nl> References: <08541957-1036-482b-331e-2000ad50aaac@dommelstein.nl> Message-ID: <20230602184407.13256fea@limapholos> On Fri, 2 Jun 2023 18:07:28 +0200 Marc Weustink via lazarus wrote: >[...] > Thats fine with me. Having the scrollbar limited to the > max(screenwidht+something, longest line) makes sense. +1 Mattias From vojtech.cihak at atlas.cz Wed Jun 7 00:35:19 2023 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=c4=9bch_=c4=8cih=c3=a1k?=) Date: Wed, 07 Jun 2023 00:35:19 +0200 Subject: [Lazarus] Hi-DPI tweak of components Message-ID: <20230607003519.9180B1E6@atlas.cz> Hi, ? I finally built a hi-DPI machine (28'' 4k display, currently set to 118PPI) and I need to tweak EC-Controls (https://wiki.freepascal.org/Eye-Candy_Controls) to scale better. One problematic is TECSpinBtns because it is designed like this: it consists of (initially) nine small buttons (TPersistent) with hardcoded width=15 and its overall width is 9*15 =135 pixels or N*15 in general. Therefore, when I put this component on the form, its Width is not scaled (Height is). I tried to override?DoAutoAdjustLayout but it's not triggered at all. TECSpinBtns?is TGraphicControl. ? Thanks, V. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Wed Jun 7 08:18:36 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 7 Jun 2023 08:18:36 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <20230607003519.9180B1E6@atlas.cz> References: <20230607003519.9180B1E6@atlas.cz> Message-ID: On 07.06.2023 00:35, Vojt?ch ?ih?k via lazarus wrote: > > I finally built a hi-DPI machine (28'' 4k display, currently set to > 118PPI) and I need to tweak EC-Controls > (https://wiki.freepascal.org/Eye-Candy_Controls) to scale better. > > One problematic is TECSpinBtns because it is designed like this: it > consists of (initially) nine small buttons (TPersistent) with > hardcoded width=15 and its overall width is 9*15 =135 pixels or N*15 > in general. > > Therefore, when I put this component on the form, its Width is not > scaled (Height is). I tried to override?DoAutoAdjustLayout but it's > not triggered at all. > > TECSpinBtns is TGraphicControl. > Here is information: https://wiki.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.8_and_above IIRC, DoAutoAdjustLayout() is executed only when the DPI changes. You have to scale every hardcoded pixel value in the constructor/loading/intitialize as well. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Wed Jun 7 08:18:36 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Wed, 7 Jun 2023 08:18:36 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <20230607003519.9180B1E6@atlas.cz> References: <20230607003519.9180B1E6@atlas.cz> Message-ID: On 07.06.2023 00:35, Vojt?ch ?ih?k via lazarus wrote: > > I finally built a hi-DPI machine (28'' 4k display, currently set to > 118PPI) and I need to tweak EC-Controls > (https://wiki.freepascal.org/Eye-Candy_Controls) to scale better. > > One problematic is TECSpinBtns because it is designed like this: it > consists of (initially) nine small buttons (TPersistent) with > hardcoded width=15 and its overall width is 9*15 =135 pixels or N*15 > in general. > > Therefore, when I put this component on the form, its Width is not > scaled (Height is). I tried to override?DoAutoAdjustLayout but it's > not triggered at all. > > TECSpinBtns is TGraphicControl. > Here is information: https://wiki.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.8_and_above IIRC, DoAutoAdjustLayout() is executed only when the DPI changes. You have to scale every hardcoded pixel value in the constructor/loading/intitialize as well. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Wed Jun 7 11:43:16 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 7 Jun 2023 11:43:16 +0200 (CEST) Subject: [Lazarus] Output directories Message-ID: Hello, There is a problem when installing Lazarus through the package manager on Linux, and when you try to install/recompile additional packages: Error: (lazarus) unable to create package output directory "/usr/share/lazarus/2.2.4/components/fpweb/lib/x86_64-linux" of package "weblaz 1.0" I suspect that the IDE tries to create the output directories of packages, but of course it has no write permission in /usr/share. Should this not be detected and the output put in ~/.local/share/lazarus/... instead ? Michael. From nc-gaertnma at netcologne.de Wed Jun 7 11:54:24 2023 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 7 Jun 2023 11:54:24 +0200 Subject: [Lazarus] Output directories In-Reply-To: References: Message-ID: <20230607115424.186e7370@limapholos> On Wed, 7 Jun 2023 11:43:16 +0200 (CEST) Michael Van Canneyt via lazarus wrote: > Hello, > > There is a problem when installing Lazarus through the package > manager on Linux, and when you try to install/recompile additional > packages: > > Error: (lazarus) unable to create package output directory > "/usr/share/lazarus/2.2.4/components/fpweb/lib/x86_64-linux" of > package "weblaz 1.0" > > I suspect that the IDE tries to create the output directories of > packages, but of course it has no write permission in /usr/share. > > Should this not be detected and the output put in > ~/.local/share/lazarus/... instead ? Yes, sounds like a regression. Mattias From giuliano.colla at fastwebnet.it Wed Jun 7 11:58:11 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Wed, 7 Jun 2023 11:58:11 +0200 Subject: [Lazarus] Output directories In-Reply-To: References: Message-ID: Il 07/06/23 11:43, Michael Van Canneyt via lazarus ha scritto: > > Hello, > > There is a problem when installing Lazarus through the package manager on > Linux, and when you try to install/recompile additional packages: > > Error: (lazarus) unable to create package output directory > "/usr/share/lazarus/2.2.4/components/fpweb/lib/x86_64-linux" of > package "weblaz 1.0" > > I suspect that the IDE tries to create the output directories of > packages, > but of course it has no write permission in /usr/share. > > Should this not be detected and the output put in > ~/.local/share/lazarus/... instead ? > > Michael. > There's a number of such bugs. When you're rebuilding Lazarus with source code in a write protected folder, your local copy is created in a local ~/.lazarus folder. Everything should be written there and the write protected folder should be left? untouched. But whenever a subfolder is needed, there is a check that it does exist in the write protected area, even if it will not be used, and an error is flagged if the folder doesn't exist and can't be created. It occurred to me with qt ws. Just sudo mkdir the missing directory in the lazarus tree, the folder is left empty, but the IDE compiles properly. Giuliano From vojtech.cihak at atlas.cz Thu Jun 8 00:46:47 2023 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=c4=9bch_=c4=8cih=c3=a1k?=) Date: Thu, 08 Jun 2023 00:46:47 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> Message-ID: <20230608004647.AF1D5A9E@atlas.cz> Thanks, ? please confirm me if I understand well the concept: 1)?when component is put on the form in designer: it?is scaled (Width & Height)? 2) when?it is put on the form later in code: it is not scaled? ? but internals are scaled in both cases (by internals I mean for example DefaultRowHeight and DefaultColWidth of TStringGrid) ? Or at least TStringGrid behaves as I described above. ? Because I need to scale internals of TGraphicControl (which has no own Canvas or Handle) I decided to do scaling in SetParent();. ? For curiosity: was tested the case when someone has two or more monitors with different DPI and moves the form (made in Lazarus) from one monitor to another? ? V. ______________________________________________________________ > Od: "Ondrej Pokorny" > Komu: "Lazarus mailing list" , lazarus at lists.lazarus.freepascal.org > Datum: 07.06.2023 08:19 > P?edm?t: Re: [Lazarus] Hi-DPI tweak of components > On 07.06.2023 00:35, Vojt?ch ?ih?k via lazarus wrote:... Here is information: https://wiki.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.8_and_above IIRC, DoAutoAdjustLayout() is executed only when the DPI changes. You have to scale every hardcoded pixel value in the constructor/loading/intitialize as well. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Thu Jun 8 07:53:28 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 07:53:28 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <20230608004647.AF1D5A9E@atlas.cz> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> Message-ID: <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> On 08.06.2023 00:46, Vojt?ch ?ih?k via lazarus wrote: > > Thanks, > > please confirm me if I understand well the concept: > > 1) when component is put on the form in designer: it is scaled (Width > & Height) > Yes. > 2) when it is put on the form later in code: it is not scaled > It depends on what you understand with "it is not scaled". If you do: MyComponent.Parent := Panel1; MyComponent.Width := 100; MyComponent.Height := 100; Then obviously the width/height is not scaled because you assigned constant numbers there. But the internals are scaled with DoAutoAdjustLayout() if the target PPI (of Panel1) is different from Screen.PixelsPerInch. > but internals are scaled in both cases (by internals I mean for > example DefaultRowHeight and DefaultColWidth of TStringGrid) > > Or at least TStringGrid behaves as I described above. > Yes. > Because I need to scale internals of TGraphicControl (which has no own > Canvas or Handle) I decided to do scaling in SetParent();. > You definitely should use DoAutoAdjustLayout(). > For curiosity: was tested the case when someone has two or more > monitors with different DPI and moves the form (made in Lazarus) from > one monitor to another? > Yes. DoAutoAdjustLayout() takes care of it. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Thu Jun 8 07:53:28 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 07:53:28 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <20230608004647.AF1D5A9E@atlas.cz> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> Message-ID: <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> On 08.06.2023 00:46, Vojt?ch ?ih?k via lazarus wrote: > > Thanks, > > please confirm me if I understand well the concept: > > 1) when component is put on the form in designer: it is scaled (Width > & Height) > Yes. > 2) when it is put on the form later in code: it is not scaled > It depends on what you understand with "it is not scaled". If you do: MyComponent.Parent := Panel1; MyComponent.Width := 100; MyComponent.Height := 100; Then obviously the width/height is not scaled because you assigned constant numbers there. But the internals are scaled with DoAutoAdjustLayout() if the target PPI (of Panel1) is different from Screen.PixelsPerInch. > but internals are scaled in both cases (by internals I mean for > example DefaultRowHeight and DefaultColWidth of TStringGrid) > > Or at least TStringGrid behaves as I described above. > Yes. > Because I need to scale internals of TGraphicControl (which has no own > Canvas or Handle) I decided to do scaling in SetParent();. > You definitely should use DoAutoAdjustLayout(). > For curiosity: was tested the case when someone has two or more > monitors with different DPI and moves the form (made in Lazarus) from > one monitor to another? > Yes. DoAutoAdjustLayout() takes care of it. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From lazarus at kluug.net Thu Jun 8 08:08:11 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 08:08:11 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: On 08.06.2023 07:53, Ondrej Pokorny via lazarus wrote: > On 08.06.2023 00:46, Vojt?ch ?ih?k via lazarus wrote: >> >> Because I need to scale internals of TGraphicControl (which has no >> own Canvas or Handle) I decided to do scaling in SetParent();. >> > You definitely should use DoAutoAdjustLayout(). > Usually the best way to do "internals" scaling is to scale them when they are needed and not to store the scaled value. Take a look at this example: * TToolButton.Paint: ? dist := FToolbar.Scale96ToFont(cHorIconTextDist); The following examples show you how to handle a scaled internal value with a default value * TCustomColorBox.ColorRectWidth * TCustomGrid.DefaultColWidth * TCustomTreeView.ExpandSignSize --- If you have values that need to be scaled you do: 1.) Initialize the sizes for Screen.PixelsPerInch in constructor: MySize := Scale96ToScreen(cMyValueAt96DPI); 2.) Use DoAutoAdjustLayout() to scale them when PPI changes: MySize := Round(MySize * AXProportion); Simple as that. Check TCustomColorBox how it handles FColorRectWidth as an example (it uses a default value and if the user overwrites it, it gets scaled in DoAutoAdjustLayout(). Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuliano.colla at fastwebnet.it Thu Jun 8 11:34:30 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Thu, 8 Jun 2023 11:34:30 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto: > Check TCustomColorBox how it handles FColorRectWidth as an example (it > uses a default value and if the user overwrites it, it gets scaled in > DoAutoAdjustLayout(). I believe that scaling for different DPI has been implemented with a shortsighted approach. IMHO the general approach should have been (or should be if someone is willing to face it) to have *two* parameters for width and height: a pixel value and a linear value (in mm, inches, whatever). If the designer or user sets the pixel value, this value is taken and used, but the linear value is? calculated. If the designer or user sets the linear value, the pixel value is calculated using the current DPI, and is used to paint the control. A new DPI will cause all pixel values to be updated from the linear values. I don't know if there are some cases where the pixel value should be retained even for a significant DPI change. A FixedPixel boolean or a zero value in the linear value might override the resizing. I understand that this would require a revision of all TControl descendants, by exposing the new properties, but I believe it to be the only way to make the DPI handling user friendly and mainly transparent to the users. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. From giuliano.colla at fastwebnet.it Thu Jun 8 11:46:11 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Thu, 8 Jun 2023 11:46:11 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: Il 08/06/2023 11:34, Giuliano Colla via lazarus ha scritto: > Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto: > >> Check TCustomColorBox how it handles FColorRectWidth as an example >> (it uses a default value and if the user overwrites it, it gets >> scaled in DoAutoAdjustLayout(). > > I believe that scaling for different DPI has been implemented with a > shortsighted approach. > IMHO the general approach should have been (or should be if someone is > willing to face it) to have *two* parameters for width and height: a > pixel value and a linear value (in mm, inches, whatever). > If the designer or user sets the pixel value, this value is taken and > used, but the linear value is? calculated. > If the designer or user sets the linear value, the pixel value is > calculated using the current DPI, and is used to paint the control. > A new DPI will cause all pixel values to be updated from the linear > values. > I don't know if there are some cases where the pixel value should be > retained even for a significant DPI change. A FixedPixel boolean or a > zero value in the linear value might override the resizing. > > I understand that this would require a revision of all TControl > descendants, by exposing the new properties, but I believe it to be > the only way to make the DPI handling user friendly and mainly > transparent to the users. > > Giuliano > An afterthought. A simpler way (or a first step) could be to keep the linear value hidden. This wouldn't require a deep LCL revision, and would make fully transparent the DPI handling. The designer sets the desired width/height to the current screen, but the linear value is stored and used whenever the DPI changes. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. From lazarus at kluug.net Thu Jun 8 11:49:42 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 11:49:42 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: On 08.06.2023 11:34, Giuliano Colla wrote: > Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto: > >> Check TCustomColorBox how it handles FColorRectWidth as an example >> (it uses a default value and if the user overwrites it, it gets >> scaled in DoAutoAdjustLayout(). > > I believe that scaling for different DPI has been implemented with a > shortsighted approach. > IMHO the general approach should have been (or should be if someone is > willing to face it) to have *two* parameters for width and height: a > pixel value and a linear value (in mm, inches, whatever). > If the designer or user sets the pixel value, this value is taken and > used, but the linear value is? calculated. > If the designer or user sets the linear value, the pixel value is > calculated using the current DPI, and is used to paint the control. > A new DPI will cause all pixel values to be updated from the linear > values. > I don't know if there are some cases where the pixel value should be > retained even for a significant DPI change. A FixedPixel boolean or a > zero value in the linear value might override the resizing. > > I understand that this would require a revision of all TControl > descendants, by exposing the new properties, but I believe it to be > the only way to make the DPI handling user friendly and mainly > transparent to the users. LOL. What advantage do you get from this approach? You get rid of rounding errors when scaling occurs? So you get rid of problems within 1px margins? And what do you have to pay for it? To double-up all current pixel (integer precision) values with other double-precision units and do conversions between them all the time? No way it is a better approach. Well, you can create your own component library from scratch that will use double-precision units for positions&sizes (Delphi FireMonkey is one example). VCL and LCL have been designed when scaling was not an issue, so you have to live with the preconditions. Ondrej From lazarus at kluug.net Thu Jun 8 11:58:10 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 11:58:10 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: On 08.06.2023 11:46, Giuliano Colla via lazarus wrote: > Il 08/06/2023 11:34, Giuliano Colla via lazarus ha scritto: > >> Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto: >> >>> Check TCustomColorBox how it handles FColorRectWidth as an example >>> (it uses a default value and if the user overwrites it, it gets >>> scaled in DoAutoAdjustLayout(). >> >> I believe that scaling for different DPI has been implemented with a >> shortsighted approach. >> IMHO the general approach should have been (or should be if someone >> is willing to face it) to have *two* parameters for width and height: >> a pixel value and a linear value (in mm, inches, whatever). >> If the designer or user sets the pixel value, this value is taken and >> used, but the linear value is? calculated. >> If the designer or user sets the linear value, the pixel value is >> calculated using the current DPI, and is used to paint the control. >> A new DPI will cause all pixel values to be updated from the linear >> values. >> I don't know if there are some cases where the pixel value should be >> retained even for a significant DPI change. A FixedPixel boolean or a >> zero value in the linear value might override the resizing. >> >> I understand that this would require a revision of all TControl >> descendants, by exposing the new properties, but I believe it to be >> the only way to make the DPI handling user friendly and mainly >> transparent to the users. >> >> Giuliano >> > > An afterthought. A simpler way (or a first step) could be to keep the > linear value hidden. This wouldn't require a deep LCL revision, and > would make fully transparent the DPI handling. The designer sets the > desired width/height to the current screen, but the linear value is > stored and used whenever the DPI changes. Well, this still could be implemented. But do not forget that the LCL must stay backwards-compatible (old code must work in new versions) and to some extend also forwards-compatible (LFM from new Lazarus versions must open in older Lazarus versions - that is valid for at least 2 latest stable versions). Especially, the LFM compatibility is an issue. All in all, an over-complicated approach with little gain. Ondrej From giuliano.colla at fastwebnet.it Thu Jun 8 12:24:17 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Thu, 8 Jun 2023 12:24:17 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> Il 08/06/23 11:58, Ondrej Pokorny via lazarus ha scritto: > All in all, an over-complicated approach with little gain. The gain would be that you do not add up rounding errors. We can't have fractional pixels, of course, but we may have the exact actual size at design/creation time, and for each different DPI the best approximation to the actual size. If you switch back and forth between two monitors with different DPI the rounding errors remain constant, they don't add up. Giuliano From jean.suzineau at wanadoo.fr Thu Jun 8 12:39:48 2023 From: jean.suzineau at wanadoo.fr (Jean SUZINEAU) Date: Thu, 8 Jun 2023 12:39:48 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: Le 08/06/2023 ? 11:34, Giuliano Colla via lazarus a ?crit?: > I believe that scaling for different DPI has been implemented with a > shortsighted approach. It would have been nice at the time of Delphi 1 in 1995 ... ;-) A few weeks ago I got some havoc trying to port some code from LCL to Delphi 10.2 / FireMonkey when coordinates switch from Integer to Single, TPoint to TPointF,? array of TPoint to TPolygon... https://github.com/jsuzineau/pascal_o_r_mapping/blob/b54853062432d7921b17a01c7b951688590a292a/delphi/pascal_o_r_mapping/03_Data/uBatpro_Element.pas#L1478 I think you can't use integer value for mm or inches. From giuliano.colla at fastwebnet.it Thu Jun 8 12:58:49 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Thu, 8 Jun 2023 12:58:49 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: <1e5d047f-d408-cbac-fdc8-10ebc9e56059@fastwebnet.it> Il 08/06/23 12:39, Jean SUZINEAU via lazarus ha scritto: > I think you can't use integer value for mm or inches. Of course you can't. But you can use integer values for hundredth of mm (that's the resolution of high quality photo-composition) or for thousandth of inch (slightly worse but still acceptable), which in a 64bit long integer would give enough space to fit a screen much wider than the Solar system! Giuliano From lazarus at kluug.net Thu Jun 8 13:12:36 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 13:12:36 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> Message-ID: <2cdf8e0b-229a-aa4f-7fd2-304351af9654@kluug.net> On 08.06.2023 12:24, Giuliano Colla wrote: > > Il 08/06/23 11:58, Ondrej Pokorny via lazarus ha scritto: >> All in all, an over-complicated approach with little gain. > > The gain would be that you do not add up rounding errors. We can't > have fractional pixels, of course, but we may have the exact actual > size at design/creation time, and for each different DPI the best > approximation to the actual size. If you switch back and forth between > two monitors with different DPI the rounding errors remain constant, > they don't add up. You have to consider that for monitor DPI scaling, incrementing series of multiplications like A * 1.5 * 1.25 * 1.75 * 2.00 * etc * etc never appear. You always have a limited count of different resolutions (usually 2) and you always switch between up- and down-scaling. Statistically the Round() function rounds up and down equal sets of float values. So, statistically, the errors cannot add up, but they fix themselves up with the count of up- and down-scaling operations. Here is my proof for switching between 2 different resolutions from start with 100%: program Project1; uses Math; const ? Resolutions: array[0..3] of Double = (1.25, 1.50, 1.75, 2.00); var ? R: Double; ? I, F: Integer; begin ? for R in Resolutions do ??? for I := 0 to 1000 do ??? begin ????? F := I; ????? // scale first up and then down ????? F := Round(F * R); ????? F := Round(F / R); ????? if not SameValue(F, I) then ??????? Writeln(I, ': ', F); ??? end; ? ReadLn; end. Run the program, and you will se that there is no starting value at 100% that would differ if you scale it up and down. ------- If you want to test scaling down and up, then there of course there will be a discrepancy between starting and ending value after 1 down- and up-scaling cycle because you lose resolution with the first division. But if you do the same up/down scaling again, you will see that every starting value ended at a well defined pair of values. The values definitely do not grow or shrink with the count of scaling operations. program Project1; uses Math; const ? Resolutions: array[0..3] of Double = (1.25, 1.50, 1.75, 2.00); var ? R: Double; ? I, F, ErrorCountInMiddleValue, ErrorCountAfterSecondScaling, MiddleValue: Integer; begin ? ErrorCountInMiddleValue := 0; ? ErrorCountAfterSecondScaling := 0; ? for R in Resolutions do ??? for I := 0 to 1000 do ??? begin ????? F := I; ????? // first scale down, then up ????? F := Round(F / R); ????? F := Round(F * R); ????? MiddleValue := F; ????? if not SameValue(F, I) then ????? begin ??????? Inc(ErrorCountInMiddleValue); ??????? // scale first down and then up ??????? F := Round(F / R); ??????? F := Round(F * R); ??????? if not SameValue(F, MiddleValue) then ??????? begin ????????? Writeln('Error after second scaling: ', I, ': ', F); ????????? Inc(ErrorCountAfterSecondScaling); ??????? end; ????? end; ??? end; ? Writeln('ErrorCountInMiddleValue: ', ErrorCountInMiddleValue); ? Writeln('ErrorCountAfterSecondScaling: ', ErrorCountAfterSecondScaling); ? ReadLn; end. As you can see, there is no starting value that would cause a constantly incrementing or decrementing series of values. Every starting value settles down on a well-defined pair of values after the second scaling. I consider my arguments as proven. Your suggestion to have a better precision units for sizes doesn't help at all. --- And even if you found some very rare combination of scaling A -> B -> C -> A of some value X that increments by 1px every time after the whole scaling cycle is performed: who cares that after so many scaling operations the window/column/... width is bigger/smaller by 1px? As I said in the beginning, the default values should not be scaled with this approach, they should be scaled always from a constant value at 100%/96 PPI. That means for them the rounding error problem does not apply. It would apply only for user-defined sizes and there it does not matter because if the size doesn't do it for the user, he can always resize the window/column/ whatever. Ondrej From lazarus at kluug.net Thu Jun 8 13:16:58 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 13:16:58 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> Message-ID: <770e032a-6de2-3f35-6a46-cb8160cc08c1@kluug.net> On 08.06.2023 12:24, Giuliano Colla wrote: > > Il 08/06/23 11:58, Ondrej Pokorny via lazarus ha scritto: >> All in all, an over-complicated approach with little gain. > > The gain would be that you do not add up rounding errors. We can't > have fractional pixels, of course, but we may have the exact actual > size at design/creation time, and for each different DPI the best > approximation to the actual size. If you switch back and forth between > two monitors with different DPI the rounding errors remain constant, > they don't add up. As I showed in my last email, switching back and forth between two monitors with different DPI the rounding errors remain constant even with the current integer-precision pixel values. The rounding errors never add up. So the problem you want to solve does not exist in the first place. Ondrej From lazarus at kluug.net Thu Jun 8 13:25:46 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 13:25:46 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <2cdf8e0b-229a-aa4f-7fd2-304351af9654@kluug.net> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> <2cdf8e0b-229a-aa4f-7fd2-304351af9654@kluug.net> Message-ID: Here is a more general proof for every possible combination of resolutions between 100% and 400% and for values [0..10000]: program Project1; uses Math; const ? Resolutions: array[0..8] of Double = (1.00, 1.25, 1.50, 1.75, 2.00, 2.50, 3.00, 3.50, 4.00); var ? SourceResultion, TargetResolution: Double; ? I, F, ErrorCountInMiddleValue, ErrorCountAfterSecondScaling, MiddleValue: Integer; begin ? ErrorCountInMiddleValue := 0; ? ErrorCountAfterSecondScaling := 0; ? for SourceResultion in Resolutions do ??? for TargetResolution in Resolutions do ????? if not SameValue(SourceResultion, TargetResolution) then ????? begin ??????? for I := 0 to 10000 do ??????? begin ????????? F := I; ????????? // scale from source to target and back ????????? F := Round(F / SourceResultion * TargetResolution); ????????? F := Round(F * SourceResultion / TargetResolution); ????????? MiddleValue := F; ????????? if not SameValue(F, I) then ????????? begin ??????????? Inc(ErrorCountInMiddleValue); ?? ???????? // scale from source to target and back again ??????????? F := Round(F / SourceResultion * TargetResolution); ??????????? F := Round(F * SourceResultion / TargetResolution); ??????????? if not SameValue(F, MiddleValue) then ??????????? begin ????????????? Writeln('Error after second scaling: ', I, ': ', F, ' SourceResultion:TargetResolution (', SourceResultion, ':', TargetResolution, ')'); ????????????? Inc(ErrorCountAfterSecondScaling); ??????????? end; ????????? end; ??????? end; ????? end; ? Writeln('ErrorCountInMiddleValue: ', ErrorCountInMiddleValue); ? Writeln('ErrorCountAfterSecondScaling: ', ErrorCountAfterSecondScaling); ? ReadLn; end. Ondrej From lazarus at kluug.net Thu Jun 8 18:40:09 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 18:40:09 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> <2cdf8e0b-229a-aa4f-7fd2-304351af9654@kluug.net> Message-ID: And because it is so much fun, I wrote a completely general program to test it. You can define how many resolution combinations you want to go through and what maximum value you want to start with and it goes through all possible combinations and gives you results after how many cycles a start-end pair has settled down and what was the maximum difference. E.g. for the most typical use-case of 2 different resolutions and max scaling of 200% and max starting value of 2000, the results are: -- Input -- Possible resolutions: 100%, 125%, 150%, 175%, 200% UniqueCombinations: True ResolutionSteps: 2 MaxValue: 2000 -- Results -- Count: 40020 Error count after the cycle #1: 5615 (14,03%) No errors after cycle #2 Maximal error value (difference between start and end value): 1 (5,88% from value 17 to 18 for combination 10) So not really bad, after the 1st cycle the value always settles down and the maximal error is 1px, which is ~6% of the start value. --------- For 3 different resolutions (100%, 125%, 200%), the maximum error value is 2px after max 10 resolution changes: -- Input -- Possible resolutions: 100%, 125%, 200% UniqueCombinations: False ResolutionSteps: 10 MaxValue: 500 -- Results -- Count: 29583048 Error count after the cycle #1: 6805918 (23,01%) No errors after cycle #2 Maximal error value (difference between start and end value): 2 (9,52% from value 21 to 19 for combination 2000000001) ---------- But even after 8 resolution steps (using 5 different resolutions), the error is not that bad: -- Input -- Possible resolutions: 100%, 125%, 150%, 175%, 200% UniqueCombinations: False ResolutionSteps: 8 MaxValue: 500 -- Results -- Count: 195702624 Error count after the cycle #1: 82854224 (42,34%) Error count after the cycle #2: 9545914 (4,88%) Error count after the cycle #3: 184165 (0,09%) No errors after cycle #4 Maximal error value (difference between start and end value): 5 (26,32% from value 19 to 14 for combination 32401201) --------- To sum it up, for 3 and less monitor DPI resolutions, the maximum error is 2px, which is marginal and it is there only for the very small value of 19px. When the number of different resolutions increases (in the above example 5 different resolutions), the error gets higher, but still is acceptable and the higher the starting value, the lower the rounding error. And honestly, who has 5 monitors and every one with a different resolution and moves a window between all of them, so that it bothers him? My conclusion is that it really is not worth it to introduce a floating-point precision sizes within the LCL. Yes, there would be some gain in scaling precision but only for a lot of different DPI values (more than 3) and the gain would not be striking. On the other hand, the effort needed would be very high, especially due to forwards compatibility of the LFM format. Ondrej Program code: program TestScaling; uses Math, SysUtils; const ? //DefResolutions: array[0..2] of Double = (1.00, 1.25, 2.00); ? DefResolutions: array[0..4] of Double = (1.00, 1.25, 1.50, 1.75, 2.00); ? //DefResolutions: array[0..8] of Double = (1.00, 1.25, 1.50, 1.75, 2.00, 2.50, 3.00, 3.50, 4.00); // test even more resolutions - up to 400% ? MaxDiffFromValue = 16; // do not test values smaller than this for MaxDiff* function Scale(const aValue: Integer; const aFromResolution, aToResolution: Double): Integer; begin ? Result := Round(aValue / aFromResolution * aToResolution); end; function ScaleCycle(const V: Integer; R: TArray): Integer; var ? I: Integer; begin ? Result := V; ? for I := 0 to High(R)-1 do ??? Result := Scale(Result, DefResolutions[R[I]], DefResolutions[R[I+1]]); ? Result := Scale(Result, DefResolutions[R[High(R)]], DefResolutions[R[0]]); end; function NextCombination(var R: TArray): Boolean; var ? I: Integer; begin ? for I := High(R) downto 0 do ? begin ??? if R[I]): Boolean; var ? I, L: Integer; begin ? for I := 0 to High(R) do ??? for L := I+1 to High(R) do ????? if R[I]=R[L] then ??????? Exit(False); ? Result := True; end; function WriteCombination(const R: TArray): string; var ? I: Integer; begin ? Result := ''; ? for I := 0 to High(R) do ??? Result := Result + IntToStr(R[I]); end; function WriteResolutions(const R: array of Double): string; var ? I: Integer; begin ? Result := ''; ? for I := 0 to High(R) do ? begin ??? if Result<>'' then ????? Result := Result + ', '; ??? Result := Result + IntToStr(Round(R[I]*100))+'%'; ? end; end; var ? Resolutions: array of Integer; ? I, F, RefValue, Cycle, ResolutionSteps, MaxValue, StartValue, MaxDiff, MaxDiffStartValue, MaxDiffEndValue: Integer; ? Count: Int64; ? MaxDiffRatio: Double; ? Errors: array of Int64; ? MaxDiffCombination: string; ? UniqueCombinationsC: Char; ? UniqueCombinations: Boolean; begin ? try ??? Write('Do you want to test only unique combinations? (y/n): '); ??? ReadLn(UniqueCombinationsC); ??? UniqueCombinations := LowerCase(UniqueCombinationsC)='y'; ??? if UniqueCombinations then ????? Write(Format('Input how many resolutions do you want to cycle through (min = 2, max = %d): ', [Length(DefResolutions)])) ??? else ????? Write('Input how many resolutions do you want to cycle through (min = 2): '); ??? ReadLn(ResolutionSteps); ??? if ResolutionSteps<2 then ????? raise EInOutError.Create('Invalid resolution count'); ??? if UniqueCombinations and (ResolutionSteps>Length(DefResolutions)) then ????? raise EInOutError.CreateFmt('Invalid resolution count (in case of unique combintations, the resolution count must be max "%d"', [Length(DefResolutions)]); ??? Write('Input the maximum value you want to test (e.g. 1000): '); ??? ReadLn(MaxValue); ??? if MaxValue<1 then ????? raise EInOutError.Create('Invalid maximum value'); ??? Resolutions := nil; ??? SetLength(Resolutions, ResolutionSteps); ??? for I := 0 to High(Resolutions) do ????? Resolutions[I] := 0; ??? Count := 0; ??? MaxDiff := 0; ??? MaxDiffRatio := 0; ??? MaxDiffStartValue := 0; ??? MaxDiffEndValue := 0; ??? MaxDiffCombination := ''; ??? Errors := nil; ??? while NextCombination(Resolutions) do ??? begin ????? if UniqueCombinations and not CombinationIsUnique(Resolutions) then ??????? continue; ????? Write('Combination: '); ????? Writeln(WriteCombination(Resolutions)); ????? for I := 0 to MaxValue do ????? begin ??????? Inc(Count); ??????? StartValue := I; ??????? RefValue := I; ??????? F := ScaleCycle(RefValue, Resolutions); ??????? Cycle := 0; ??????? while not SameValue(F, RefValue) do ??????? begin ????????? // compute MaxDiff - but only for values above MaxDiffFromValue ????????? if (StartValue>=MaxDiffFromValue) ????????? and (MaxDiff References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> <2cdf8e0b-229a-aa4f-7fd2-304351af9654@kluug.net> Message-ID: <224915f6-f7e1-4fd2-9266-93dfdf349ca7@fastwebnet.it> Il 08/06/23 18:40, Ondrej Pokorny via lazarus ha scritto: > And because it is so much fun, I wrote a completely general program to > test it. Well you've shown that it isn't so bad. But there's another detail to consider, when resizing: font size. Font size can (and should be) specified in typographic points, in order to ensure that text is both readable and not too large. i.e. in units which are 1/72". Resizing when text size is specified in inches, i.e. in its actual, system independent, size, while width and height are specified in pixels i.e. in system dependent units is the best way to create the mess which is there since the early times of Delphi. Giuliano From lazarus at kluug.net Thu Jun 8 19:38:12 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 8 Jun 2023 19:38:12 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <224915f6-f7e1-4fd2-9266-93dfdf349ca7@fastwebnet.it> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <2f13e09f-91d6-def7-5eca-185eb3c44066@fastwebnet.it> <2cdf8e0b-229a-aa4f-7fd2-304351af9654@kluug.net> <224915f6-f7e1-4fd2-9266-93dfdf349ca7@fastwebnet.it> Message-ID: <7ef1ac62-aa97-a198-1840-9d83170c33ba@kluug.net> On 08.06.2023 19:30, Giuliano Colla wrote: > Il 08/06/23 18:40, Ondrej Pokorny via lazarus ha scritto: > >> And because it is so much fun, I wrote a completely general program >> to test it. > > Well you've shown that it isn't so bad. But there's another detail to > consider, when resizing: font size. Font size can (and should be) > specified in typographic points, in order to ensure that text is both > readable and not too large. i.e. in units which are 1/72". Resizing > when text size is specified in inches, i.e. in its actual, system > independent, size, while width and height are specified in pixels i.e. > in system dependent units is the best way to create the mess which is > there since the early times of Delphi. Font size/height are not scaled. The TFont.PixelsPerInch property is directly assigned to the target value, so there cannot be a scaling problem there. See TControl.ScaleFontsPPI and TControl.DoScaleFontPPI. Ondrej From juha.manninen62 at gmail.com Sun Jun 11 20:15:24 2023 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sun, 11 Jun 2023 21:15:24 +0300 Subject: [Lazarus] Build Lazarus trunk clean Message-ID: I did some refactoring in Lazarus sources. At least one file was moved and dependencies changed. It may require building clean to avoid "incompatible .ppu file" warnings and similar. Regards, Juha -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmlandmesser at gmx.de Sun Jun 11 21:07:20 2023 From: jmlandmesser at gmx.de (John Landmesser) Date: Sun, 11 Jun 2023 21:07:20 +0200 Subject: [Lazarus] Build Lazarus trunk clean In-Reply-To: References: Message-ID: <9cabae12-3617-e550-a5c4-b3b2fa054f07@gmx.de> Am 11.06.23 um 20:15 schrieb Juha Manninen via lazarus: > I did some refactoring in Lazarus sources. At least one file was moved > and dependencies changed. > It may require building clean to avoid "incompatible .ppu file" > warnings and similar. > > Regards, > Juha > > I can compile? lazarus trunk from within the IDE: > Lazarus 2.3.0 (rev main-2_3-3623-gec14525a1a) FPC 3.2.2 x86_64-linux-gtk2 But if i git pull to a fresh lazarus folder i get this error: make all clean useride > (3104) Compiling inputhistory.pas > /home/john1/lazarus/components/ideintf/inputhistory.pas(46,3) Fatal: > (10022) Can't find unit FileProcs used by InputHistory > Fatal: (1018) Compilation aborted > make[1]: *** [Makefile:3745: ideintf.ppu] Fehler 1 > make[1]: Verzeichnis ?/home/john1/lazarus/components/ideintf? wird > verlassen > make: *** [Makefile:3870: lazbuild] Fehler 2 Whats the difference between these two methods? From juha.manninen62 at gmail.com Sun Jun 11 23:25:27 2023 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 12 Jun 2023 00:25:27 +0300 Subject: [Lazarus] Build Lazarus trunk clean In-Reply-To: <9cabae12-3617-e550-a5c4-b3b2fa054f07@gmx.de> References: <9cabae12-3617-e550-a5c4-b3b2fa054f07@gmx.de> Message-ID: On Sunday, June 11, 2023, John Landmesser via lazarus < lazarus at lists.lazarus-ide.org> wrote: > make all clean useride > > (3104) Compiling inputhistory.pas >> /home/john1/lazarus/components/ideintf/inputhistory.pas(46,3) Fatal: >> (10022) Can't find unit FileProcs used by InputHistory >> Fatal: (1018) Compilation aborted >> make[1]: *** [Makefile:3745: ideintf.ppu] Fehler 1 >> make[1]: Verzeichnis ?/home/john1/lazarus/components/ideintf? wird >> verlassen >> make: *** [Makefile:3870: lazbuild] Fehler 2 >> > > Whats the difference between these two methods? > Yes I screwed again with the makefiles. They are nasty. Hold on ... There are 2 build systems. Building from the IDE does not use makefiles at all. Juha -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Sun Jun 11 23:36:40 2023 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Mon, 12 Jun 2023 00:36:40 +0300 Subject: [Lazarus] Build Lazarus trunk clean In-Reply-To: References: <9cabae12-3617-e550-a5c4-b3b2fa054f07@gmx.de> Message-ID: Please test again. Mattias generated the makefiles and saved me once again. Juha -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmlandmesser at gmx.de Mon Jun 12 12:14:32 2023 From: jmlandmesser at gmx.de (John Landmesser) Date: Mon, 12 Jun 2023 12:14:32 +0200 Subject: [Lazarus] Build Lazarus trunk clean In-Reply-To: References: <9cabae12-3617-e550-a5c4-b3b2fa054f07@gmx.de> Message-ID: Am 11.06.23 um 23:36 schrieb Juha Manninen via lazarus: > Please test again. Mattias generated the makefiles and saved me once > again. > > Juha > > Works again :-) Thank you Juha & Mattias! From giuliano.colla at fastwebnet.it Mon Jun 12 13:35:28 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Mon, 12 Jun 2023 13:35:28 +0200 Subject: [Lazarus] Qt5 IDE fails to build on Linux Message-ID: Attempting to build latest Lazarus trunk on Linux CentOs7 with Qt5 fails with error: /home/colla/Applicazioni/lazarus_main/lcl/interfaces//qt5/qtobject.inc:44: undefined reference to `QGuiApplication_setFallbackSessionManagementEnabled' It succeeds setting {$DEFINE QT_NO_SESSIONMANAGER} in qtdefines.inc My cbindings outdated or bug? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. From zeljko at holobit.hr Mon Jun 12 15:22:53 2023 From: zeljko at holobit.hr (zeljko) Date: Mon, 12 Jun 2023 15:22:53 +0200 Subject: [Lazarus] Qt5 IDE fails to build on Linux In-Reply-To: References: Message-ID: On 12. 06. 2023. 13:35, Giuliano Colla via lazarus wrote: > Attempting to build latest Lazarus trunk on Linux CentOs7 with Qt5 fails > with error: > > /home/colla/Applicazioni/lazarus_main/lcl/interfaces//qt5/qtobject.inc:44: undefined reference to `QGuiApplication_setFallbackSessionManagementEnabled' > > It succeeds setting > > {$DEFINE QT_NO_SESSIONMANAGER} > > in qtdefines.inc > > My cbindings outdated or bug? Your bindings are outdated. If you use trunk lazarus then you must build your own bindings. Besides that, bindings won't change soon, so current trunk libQt5Pas v.1.2.13 will be pushed to 2.4 and distros. zeljko From zeljko at holobit.hr Mon Jun 12 15:22:53 2023 From: zeljko at holobit.hr (zeljko) Date: Mon, 12 Jun 2023 15:22:53 +0200 Subject: [Lazarus] Qt5 IDE fails to build on Linux In-Reply-To: References: Message-ID: On 12. 06. 2023. 13:35, Giuliano Colla via lazarus wrote: > Attempting to build latest Lazarus trunk on Linux CentOs7 with Qt5 fails > with error: > > /home/colla/Applicazioni/lazarus_main/lcl/interfaces//qt5/qtobject.inc:44: undefined reference to `QGuiApplication_setFallbackSessionManagementEnabled' > > It succeeds setting > > {$DEFINE QT_NO_SESSIONMANAGER} > > in qtdefines.inc > > My cbindings outdated or bug? Your bindings are outdated. If you use trunk lazarus then you must build your own bindings. Besides that, bindings won't change soon, so current trunk libQt5Pas v.1.2.13 will be pushed to 2.4 and distros. zeljko From md at delfire.net Wed Jun 14 03:58:40 2023 From: md at delfire.net (Marcos Douglas B. Santos) Date: Tue, 13 Jun 2023 22:58:40 -0300 Subject: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle Message-ID: Hi, I'm trying to run Sciter.TIS https://sciter.com/download/ on Lazarus, which could be an open source project in the future ? yes, not the newer version (named Sciter.JS) as I don't need these new features. I've started looking into https://github.com/da-baranov/SciDe (~8 years ago). Then, I discovered a fork https://github.com/Mikanoshi/SciDe (~5 years old) and forked from it because it is "newer". The da-baranov's original repository already tried to run on Lazarus, but they have an issue which couldn't be solved: https://github.com/da-baranov/SciDe/issues/3#issuecomment-87698772 I have the same issue, even using the newer version... When it calls API.SciterWindowAttachEventHandler() here https://github.com/Mikanoshi/SciDe/blob/master/source/Sciter.pas#L1439-L1440, the result is always SCDOM_INVALID_HWND. Why am I asking this here? Well, the project claims that it works from Delphi 7 to newer; they could compile on Lazarus; I also could compile (creating a package, a component, etc) on Lazarus; but it do not work because something looks like different about how a Handle works on VCL comparing to LCL. Please, do you have any ideas? Best regards, Marcos Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Wed Jun 14 11:47:19 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 14 Jun 2023 09:47:19 +0000 (UTC) Subject: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle In-Reply-To: References: Message-ID: On Tue, 13 Jun 2023, Marcos Douglas B. Santos via lazarus wrote: > Hi, > I'm trying to run Sciter.TIS https://sciter.com/download/ on Lazarus, which could be an open source project in the future ? yes, > not the newer version (named Sciter.JS) as I don't need these new features. > > I've started looking into https://github.com/da-baranov/SciDe (~8 years ago). Then, I discovered a fork > https://github.com/Mikanoshi/SciDe (~5 years old) and forked from it because it is "newer". > > The?da-baranov's original repository already tried to run on Lazarus, but they have an issue which couldn't be solved: > https://github.com/da-baranov/SciDe/issues/3#issuecomment-87698772 If you look at the issue, you see there is a commit that claims to solve this issue. Did you test if that commit is incorporated in your code ? > > I have the same issue, even using the newer version... > When it calls?API.SciterWindowAttachEventHandler() here > https://github.com/Mikanoshi/SciDe/blob/master/source/Sciter.pas#L1439-L1440, the result is always?SCDOM_INVALID_HWND. > > Why am I asking this here? Well, the project claims that it works from Delphi 7 to newer; they could compile on Lazarus; I also > could compile (creating a package, a component, etc) on Lazarus; but it do not work because something looks like different about > how a Handle works on VCL comparing to LCL. On windows, the handle should work the same. If you're working on another platform, then it works very different, and then you'll need to see what sciter actually expects. Michael. From md at delfire.net Wed Jun 14 12:43:38 2023 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 14 Jun 2023 07:43:38 -0300 Subject: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle In-Reply-To: References: Message-ID: On Wed, Jun 14, 2023 at 6:47?AM Michael Van Canneyt via lazarus wrote: > > On Tue, 13 Jun 2023, Marcos Douglas B. Santos via lazarus wrote: > > > Hi, > > I'm trying to run Sciter.TIS https://sciter.com/download/ on Lazarus, which could be an open source project in the future ? yes, > > not the newer version (named Sciter.JS) as I don't need these new features. > > > > I've started looking into https://github.com/da-baranov/SciDe (~8 years ago). Then, I discovered a fork > > https://github.com/Mikanoshi/SciDe (~5 years old) and forked from it because it is "newer". > > > > The da-baranov's original repository already tried to run on Lazarus, but they have an issue which couldn't be solved: > > https://github.com/da-baranov/SciDe/issues/3#issuecomment-87698772 > > If you look at the issue, you see there is a commit that claims to solve > this issue. Did you test if that commit is incorporated in your code ? Yes, it is incorporated. First I checked it, but later forked the repository from the author of this commit (mr. Mikanoshi), which is newer... But it didn't work. > > I have the same issue, even using the newer version... > > When it calls API.SciterWindowAttachEventHandler() here > > https://github.com/Mikanoshi/SciDe/blob/master/source/Sciter.pas#L1439-L1440, the result is always SCDOM_INVALID_HWND. > > > > Why am I asking this here? Well, the project claims that it works from Delphi 7 to newer; they could compile on Lazarus; I also > > could compile (creating a package, a component, etc) on Lazarus; but it do not work because something looks like different about > > how a Handle works on VCL comparing to LCL. > > On windows, the handle should work the same. If you're working on another > platform, then it works very different, and then you'll need to see what sciter > actually expects. I would like it to work on Windows, Linux and MacOS, but for now I will be glad that it only works on Windows. Marcos Douglas From vojtech.cihak at atlas.cz Wed Jun 14 21:52:25 2023 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=c4=9bch_=c4=8cih=c3=a1k?=) Date: Wed, 14 Jun 2023 21:52:25 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz>, , <20230608004647.AF1D5A9E@atlas.cz>, <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> Message-ID: <20230614215225.C52676D4@atlas.cz> Hi, I have one more question to?DoAutoAdjustLayout();. I use TECSpinBtns (TGraphicControl) in two variants: The first as a stand-alone component and the second as a part of TECSpinEdit (where TEdit is Owner and TECSpinBtns is subcomponent anchored to it). When I put them on the form,?DoAutoAdjustLayout()?is triggered only in the first case. Is it that Owner is responsible to call?DoAutoAdjustLayout()?of owned controls? ? V. ______________________________________________________________ > Od: "Ondrej Pokorny via lazarus" > Komu: lazarus at lists.lazarus-ide.org > Datum: 08.06.2023 08:08 > P?edm?t: Re: [Lazarus] Hi-DPI tweak of components > ---If you have values that need to be scaled you do: 1.) Initialize the sizes for Screen.PixelsPerInch in constructor: MySize := Scale96ToScreen(cMyValueAt96DPI); 2.) Use DoAutoAdjustLayout() to scale them when PPI changes: MySize := Round(MySize * AXProportion); Simple as that. Check TCustomColorBox how it handles FColorRectWidth as an example (it uses a default value and if the user overwrites it, it gets scaled in DoAutoAdjustLayout(). Ondrej ---------- -- _______________________________________________ lazarus mailing list lazarus at lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Wed Jun 14 22:22:27 2023 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 14 Jun 2023 17:22:27 -0300 Subject: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle In-Reply-To: References: Message-ID: On Wed, Jun 14, 2023 at 7:43?AM Marcos Douglas B. Santos wrote: > > On Wed, Jun 14, 2023 at 6:47?AM Michael Van Canneyt via lazarus > wrote: > > > > On Tue, 13 Jun 2023, Marcos Douglas B. Santos via lazarus wrote: > > > > > Hi, > > > I'm trying to run Sciter.TIS https://sciter.com/download/ on Lazarus, which could be an open source project in the future ? yes, > > > not the newer version (named Sciter.JS) as I don't need these new features. > > > > > > I've started looking into https://github.com/da-baranov/SciDe (~8 years ago). Then, I discovered a fork > > > https://github.com/Mikanoshi/SciDe (~5 years old) and forked from it because it is "newer". > > > > > > The da-baranov's original repository already tried to run on Lazarus, but they have an issue which couldn't be solved: > > > https://github.com/da-baranov/SciDe/issues/3#issuecomment-87698772 > > > > If you look at the issue, you see there is a commit that claims to solve > > this issue. Did you test if that commit is incorporated in your code ? > > Yes, it is incorporated. First I checked it, but later forked the > repository from the author of this commit (mr. Mikanoshi), which is > newer... > But it didn't work. > > > > I have the same issue, even using the newer version... > > > When it calls API.SciterWindowAttachEventHandler() here > > > https://github.com/Mikanoshi/SciDe/blob/master/source/Sciter.pas#L1439-L1440, the result is always SCDOM_INVALID_HWND. > > > > > > Why am I asking this here? Well, the project claims that it works from Delphi 7 to newer; they could compile on Lazarus; I also > > > could compile (creating a package, a component, etc) on Lazarus; but it do not work because something looks like different about > > > how a Handle works on VCL comparing to LCL. > > > > On windows, the handle should work the same. If you're working on another > > platform, then it works very different, and then you'll need to see what sciter > > actually expects. > > I would like it to work on Windows, Linux and MacOS, but for now I > will be glad that it only works on Windows. Michael, Do you have any more ideas to try to solve this issue? Thanks, best regards, Marcos Douglas From michael at freepascal.org Wed Jun 14 23:45:03 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 14 Jun 2023 21:45:03 +0000 (UTC) Subject: [Lazarus] Sciter for Lazarus: VCL Handle vs. LCL Handle In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023, Marcos Douglas B. Santos wrote: >>> On windows, the handle should work the same. If you're working on another >>> platform, then it works very different, and then you'll need to see what sciter >>> actually expects. >> >> I would like it to work on Windows, Linux and MacOS, but for now I >> will be glad that it only works on Windows. > > Michael, > Do you have any more ideas to try to solve this issue? I think that first of all the result of API.SciterSetCallback (2 lines before) needs to be checked. If this also gives an error, then we at least know the window handle is totally not OK. If that does not give an error, then I think it means the createparams are not OK for the event handler. It can be that the customcontrol window handle is created with different create params than the one in Delphi. I don't know how to check this. There is also 'HANDLE_ALL' which requests event handling for all kinds of events, including DND So I would also change HANDLE_ALL to something like HANDLE_MOUSE OR HANDLE_KEY OR HANDLE_FOCUS Because maybe the window handle is not created with the correct parameters for HANDLE_ALL. I found some Go code that initializes OLE stuff for the window, and I would be surprised if Lazarus does this by default; if HANDLE_ALL also must handle OLE messages, then it can be it fails for those messages. Unfortunately, the sciter documentation is very unclear in terms of what is expected of the window handle. Michael. From lazarus at kluug.net Thu Jun 15 08:33:51 2023 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 15 Jun 2023 08:33:51 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: <20230614215225.C52676D4@atlas.cz> References: <20230607003519.9180B1E6@atlas.cz> <20230608004647.AF1D5A9E@atlas.cz> <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net> <20230614215225.C52676D4@atlas.cz> Message-ID: On 14.06.2023 21:52, Vojt?ch ?ih?k via lazarus wrote: > > Hi, > > > I have one more question to DoAutoAdjustLayout();. > > I use TECSpinBtns (TGraphicControl) in two variants: > > The first as a stand-alone component and the second as a part of > TECSpinEdit (where TEdit is Owner and TECSpinBtns is subcomponent > anchored to it). > > When I put them on the form, DoAutoAdjustLayout()?is triggered only in > the first case. > > Is it that Owner is responsible to call DoAutoAdjustLayout()?of owned > controls? > This is strange. All controls should be adjusted regardless of the Owner. TLabeledEdit works fine (edit that has an attached label). Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From vojtech.cihak at atlas.cz Sat Jun 17 18:46:16 2023 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=c4=9bch_=c4=8cih=c3=a1k?=) Date: Sat, 17 Jun 2023 18:46:16 +0200 Subject: [Lazarus] Hi-DPI tweak of components In-Reply-To: References: <20230607003519.9180B1E6@atlas.cz>, , <20230608004647.AF1D5A9E@atlas.cz>, <899a469d-a732-dcea-46fd-f34b943b82d8@kluug.net>, , <20230614215225.C52676D4@atlas.cz> Message-ID: <20230617184616.E063D4DC@atlas.cz> TLabeledEdit is probably not a good example since both TEdit and TLabel are native widgets (maybe they scale by widgetset) and there is some Spacing between them hardcoded to 3px. I cannot see any scaling related code in this simple component. ? Anyway, I know what's going on: ? procedure TWinControl.AutoAdjustLayout(AMode: TLayoutAdjustmentPolicy; ? const AFromPPI, AToPPI, AOldFormWidth, ANewFormWidth: Integer); var ? i: Integer; begin ? DisableAutoSizing{$IFDEF DebugDisableAutoSizing}('TWinControl.AutoAdjustLayout'){$ENDIF}; ? try ? ? for i:=0 to ControlCount-1 do ? ? ? Controls[i].AutoAdjustLayout(AMode, AFromPPI, AToPPI, AOldFormWidth, ANewFormWidth); ? ? inherited; ? finally ? ? EnableAutoSizing{$IFDEF DebugDisableAutoSizing}('TWinControl.AutoAdjustLayout'){$ENDIF}; ? end; end; ? i.e. form loops all its children and scale them. But when component is dropped on the form, scaling is done before Parent is set. Therefore only main component's DoAutoAdjustLayout is called, subcomponent is ommited. ? I noticed that it is opposite when loading from *.lfm. There scaling done after the Parent is set, so both component's and subcomponent's?DoAutoAdjustLayout is called. ? It's fine since there are simplier ways how to do initial scaling (when component is created and put on the form). ? Thanks, I only needed to understand better how it works. ? ______________________________________________________________ > Od: "Ondrej Pokorny" > Komu: "Lazarus mailing list" > Datum: 15.06.2023 08:35 > P?edm?t: Re: [Lazarus] Hi-DPI tweak of components > On 14.06.2023 21:52, Vojt?ch ?ih?k via lazarus wrote:This is strange. All controls should be adjusted regardless of the Owner. TLabeledEdit works fine (edit that has an attached label). Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Wed Jun 21 18:00:49 2023 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 21 Jun 2023 18:00:49 +0200 Subject: [Lazarus] Output directories In-Reply-To: References: Message-ID: <20230621180049.0d500435@limapholos> On Wed, 7 Jun 2023 11:58:11 +0200 Giuliano Colla via lazarus wrote: >[...] > When you're rebuilding Lazarus with source code in a write protected > folder, your local copy is created in a local ~/.lazarus folder. > Everything should be written there and the write protected folder > should be left? untouched. But whenever a subfolder is needed, there > is a check that it does exist in the write protected area, even if it > will not be used, and an error is flagged if the folder doesn't exist > and can't be created. Fixed. Mattias From jmlandmesser at gmx.de Fri Jun 30 12:18:36 2023 From: jmlandmesser at gmx.de (John Landmesser) Date: Fri, 30 Jun 2023 12:18:36 +0200 Subject: [Lazarus] Lazarus trunk version number Message-ID: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> perhaps that should have become 3.00 ? > Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 x86_64-linux-gtk2 Yes, Just a number! -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Fri Jun 30 12:26:26 2023 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 30 Jun 2023 13:26:26 +0300 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> Message-ID: On Friday, June 30, 2023, John Landmesser via lazarus < lazarus at lists.lazarus-ide.org> wrote: > perhaps that should have become 3.00 ? > > Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 x86_64-linux-gtk2 > > You are looking at trunk, the development version. See : https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer Juha -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Fri Jun 30 12:51:06 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 30 Jun 2023 12:51:06 +0200 (CEST) Subject: [Lazarus] Lazarus trunk version number In-Reply-To: References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> Message-ID: On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: > On Friday, June 30, 2023, John Landmesser via lazarus < > lazarus at lists.lazarus-ide.org> wrote: > >> perhaps that should have become 3.00 ? >> >> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 x86_64-linux-gtk2 >> >> You are looking at trunk, the development version. See : > https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer You might want to add some explanation for this new versioning scheme to that page. The graph does not help. >From what is currently there, I don't understand neither the logic nor the need of this change. Also, how come trunk is 3.99 (indicating development for 4.0, if I understand the page correctly) if 3.0 is not yet out ? Based on the graph, I would think trunk should be at 2.99 now. Michael. From lazarus at mfriebe.de Fri Jun 30 13:27:48 2023 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 30 Jun 2023 13:27:48 +0200 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> Message-ID: <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote: > > > On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: > >> On Friday, June 30, 2023, John Landmesser via lazarus < >> lazarus at lists.lazarus-ide.org> wrote: >> >>> perhaps that should have become 3.00 ? >>> >>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 >>> x86_64-linux-gtk2 >>> >>> You are looking at trunk, the development version. See : >> https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer > > You might want to add some explanation for this new versioning scheme > to that page. Added. > The graph does not help. > > From what is currently there, I don't understand neither the logic nor > the need of this change. "Need"... Well, in terms of "because it solved the issue xyz" => then there is no need. But, there was no need (anymore) to reserve 2 digits for major releases. When 1.0 was released there was no need for further major releases to be 1.2 instead of 2.0. So simple said a non-needed feature was abandoned, subjectively simplifying the process. > > Also, how come trunk is 3.99 (indicating development for 4.0, if I > understand > the page correctly) if 3.0 is not yet out ? Based on the graph, I > would think trunk should be at 2.99 now. The fixes_3 branch does exist. So the features for 3.0 have been finalized. Trunk therefore from this point prepares for 4.0. From lazarus at mfriebe.de Fri Jun 30 13:42:07 2023 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 30 Jun 2023 13:42:07 +0200 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> Message-ID: <798445d2-71c0-3ec3-113a-f6012a3e8cc7@mfriebe.de> On 30/06/2023 13:27, Martin Frb via lazarus wrote: > > But, there was no need (anymore) to reserve 2 digits for major > releases. When 1.0 was released there was no need for further major > releases to be 1.2 instead of 2.0. I forgot to add the explanation for "anymore" Prior to 1.0 the minor and patch numbers were used: 0.minor.patch But therefore the "major" number was not used (always 0). Since Lazarus became stable, the major number became 1 and it became available for use. Yet - without perceivable need - minor and patch were kept in used too. Making it 3 digits to be used. When only 2 were needed. From michael at freepascal.org Fri Jun 30 14:04:09 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 30 Jun 2023 14:04:09 +0200 (CEST) Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <798445d2-71c0-3ec3-113a-f6012a3e8cc7@mfriebe.de> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <798445d2-71c0-3ec3-113a-f6012a3e8cc7@mfriebe.de> Message-ID: On Fri, 30 Jun 2023, Martin Frb via lazarus wrote: > On 30/06/2023 13:27, Martin Frb via lazarus wrote: >> >> But, there was no need (anymore) to reserve 2 digits for major releases. >> When 1.0 was released there was no need for further major releases to be >> 1.2 instead of 2.0. > > I forgot to add the explanation for "anymore" > > Prior to 1.0 the minor and patch numbers were used: 0.minor.patch > But therefore the "major" number was not used (always 0). > > Since Lazarus became stable, the major number became 1 and it became > available for use. Yet - without perceivable need - minor and patch were kept > in used too. Making it 3 digits to be used. When only 2 were needed. So basically you did a shift left of the version number ? Michael. From lazarus at mfriebe.de Fri Jun 30 14:09:20 2023 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 30 Jun 2023 14:09:20 +0200 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <798445d2-71c0-3ec3-113a-f6012a3e8cc7@mfriebe.de> Message-ID: <680276f6-f10c-6f9b-be5a-b782da3b600b@mfriebe.de> On 30/06/2023 14:04, Michael Van Canneyt via lazarus wrote: > > So basically you did a shift left of the version number ? Not exactly, that would mean that major releases would be 4.0 and 6.0. Leaving 3 and 5 for development versions. - We combined the first 2 digits into one. (because there separation had no meaning) - Except for "trunk" development, which now got the .99 minor. - for fixes releases and fixes development, the "patch" moved left to the "minor" Or, yes: A shift left, the unallocated the odd trunk-developments, and reassigned them a .99. From ganmax at narod.ru Fri Jun 30 15:44:17 2023 From: ganmax at narod.ru (Maxim Ganetsky) Date: Fri, 30 Jun 2023 16:44:17 +0300 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> Message-ID: <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> 30.06.2023 14:27, Martin Frb via lazarus ?????: > On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote: >> >> >> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: >> >>> On Friday, June 30, 2023, John Landmesser via lazarus < >>> lazarus at lists.lazarus-ide.org> wrote: >>> >>>> perhaps that should have become 3.00 ? >>>> >>>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 >>>> x86_64-linux-gtk2 >>>> >>>> You are looking at trunk, the development version. See : >>> https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer >> >> You might want to add some explanation for this new versioning scheme >> to that page. > > Added. I made some improvements, hope it is even more clear now. >> The graph does not help. >> >> From what is currently there, I don't understand neither the logic >> nor the need of this change. > "Need"... Well, in terms of "because it solved the issue xyz" => then > there is no need. Basically, version numbering is all about "marketing". By always increasing major version we tell to the general audience that major release indeed contains major changes (which is always the case). So we solve/improve "marketing" issues. -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From ganmax at narod.ru Fri Jun 30 15:48:09 2023 From: ganmax at narod.ru (Maxim Ganetsky) Date: Fri, 30 Jun 2023 16:48:09 +0300 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> Message-ID: <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> 30.06.2023 16:44, Maxim Ganetsky via lazarus ?????: > 30.06.2023 14:27, Martin Frb via lazarus ?????: >> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote: >>> >>> >>> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: >>> >>>> On Friday, June 30, 2023, John Landmesser via lazarus < >>>> lazarus at lists.lazarus-ide.org> wrote: >>>> >>>>> perhaps that should have become 3.00 ? >>>>> >>>>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 >>>>> x86_64-linux-gtk2 >>>>> >>>>> You are looking at trunk, the development version. See : >>>> https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer >>> >>> You might want to add some explanation for this new versioning >>> scheme to that page. >> >> Added. > > I made some improvements, hope it is even more clear now. > >>> The graph does not help. >>> >>> From what is currently there, I don't understand neither the logic >>> nor the need of this change. >> "Need"... Well, in terms of "because it solved the issue xyz" => then >> there is no need. > > Basically, version numbering is all about "marketing". By always > increasing major version we tell to the general audience that major > release indeed contains major changes (which is always the case). > > So we solve/improve "marketing" issues. > BTW, in my opinion FPC has similar issues and will benefit from such approach to versioning too. -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From michael at freepascal.org Fri Jun 30 15:49:50 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 30 Jun 2023 15:49:50 +0200 (CEST) Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> Message-ID: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: > 30.06.2023 14:27, Martin Frb via lazarus ?????: >> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote: >>> >>> >>> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote: >>> >>>> On Friday, June 30, 2023, John Landmesser via lazarus < >>>> lazarus at lists.lazarus-ide.org> wrote: >>>> >>>>> perhaps that should have become 3.00 ? >>>>> >>>>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 >>>>> x86_64-linux-gtk2 >>>>> >>>>> You are looking at trunk, the development version. See : >>>> https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer >>> >>> You might want to add some explanation for this new versioning scheme >>> to that page. >> >> Added. > > I made some improvements, hope it is even more clear now. > >>> The graph does not help. >>> >>> From what is currently there, I don't understand neither the logic >>> nor the need of this change. >> "Need"... Well, in terms of "because it solved the issue xyz" => then >> there is no need. > > Basically, version numbering is all about "marketing". By always > increasing major version we tell to the general audience that major > release indeed contains major changes (which is always the case). > > So we solve/improve "marketing" issues. Thanks to all for the explanations, all is clear now ! Michael. From michael at freepascal.org Fri Jun 30 15:55:45 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 30 Jun 2023 15:55:45 +0200 (CEST) Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> Message-ID: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: >> Basically, version numbering is all about "marketing". By always >> increasing major version we tell to the general audience that major >> release indeed contains major changes (which is always the case). >> >> So we solve/improve "marketing" issues. >> > BTW, in my opinion FPC has similar issues and will benefit from such > approach to versioning too. That was funny to read :-) I think the biggest issue in this regard is actually making releases to begin with. Michael. From ganmax at narod.ru Fri Jun 30 16:08:26 2023 From: ganmax at narod.ru (Maxim Ganetsky) Date: Fri, 30 Jun 2023 17:08:26 +0300 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> Message-ID: <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru> 30.06.2023 16:55, Michael Van Canneyt via lazarus ?????: > > > On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: > >>> Basically, version numbering is all about "marketing". By always >>> increasing major version we tell to the general audience that major >>> release indeed contains major changes (which is always the case). >>> >>> So we solve/improve "marketing" issues. >>> >> BTW, in my opinion FPC has similar issues and will benefit from such >> approach to versioning too. > > That was funny to read :-) > > I think the biggest issue in this regard is actually making releases > to begin with. Yes indeed, but then in case of rare releases it is even more important to have right version numbering. :) Changing versioning is an easy and logical move in any case, why not do it? -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From michael at freepascal.org Fri Jun 30 16:25:47 2023 From: michael at freepascal.org (Michael Van Canneyt) Date: Fri, 30 Jun 2023 16:25:47 +0200 (CEST) Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru> Message-ID: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: > 30.06.2023 16:55, Michael Van Canneyt via lazarus ?????: >> >> >> On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: >> >>>> Basically, version numbering is all about "marketing". By always >>>> increasing major version we tell to the general audience that major >>>> release indeed contains major changes (which is always the case). >>>> >>>> So we solve/improve "marketing" issues. >>>> >>> BTW, in my opinion FPC has similar issues and will benefit from such >>> approach to versioning too. >> >> That was funny to read :-) >> >> I think the biggest issue in this regard is actually making releases >> to begin with. > > Yes indeed, but then in case of rare releases it is even more important > to have right version numbering. :) > > Changing versioning is an easy and logical move in any case, why not do it? That was even more funny to read... Honestly: I'll settle for actually managing to get a release out. Michael. From ganmax at narod.ru Fri Jun 30 16:35:08 2023 From: ganmax at narod.ru (Maxim Ganetsky) Date: Fri, 30 Jun 2023 17:35:08 +0300 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru> Message-ID: 30.06.2023 17:25, Michael Van Canneyt via lazarus ?????: > > > On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: > >> 30.06.2023 16:55, Michael Van Canneyt via lazarus ?????: >>> >>> >>> On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: >>> >>>>> Basically, version numbering is all about "marketing". By always >>>>> increasing major version we tell to the general audience that >>>>> major release indeed contains major changes (which is always the >>>>> case). >>>>> >>>>> So we solve/improve "marketing" issues. >>>>> >>>> BTW, in my opinion FPC has similar issues and will benefit from >>>> such approach to versioning too. >>> >>> That was funny to read :-) >>> >>> I think the biggest issue in this regard is actually making releases >>> to begin with. >> >> Yes indeed, but then in case of rare releases it is even more >> important to have right version numbering. :) >> >> Changing versioning is an easy and logical move in any case, why not >> do it? > > That was even more funny to read... > > Honestly: I'll settle for actually managing to get a release out. Yes indeed, this is most important. But I fail to see how these moves contradict each other. In any case, this is relevant only for the next major release (so next major version of FPC will be e.g. 4.0, not 3.4.0 ). And yes, this is minor issue/move, but still is IMO important (it is always wise to show to the general audience that the project is alive and kicking, which is indeed the case for FPC compiler too). But again, by any means, I do not insist on this. It is just a suggestion to consider. -- Best regards, Maxim Ganetsky mailto:ganmax at narod.ru From nc-gaertnma at netcologne.de Fri Jun 30 19:40:37 2023 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Fri, 30 Jun 2023 19:40:37 +0200 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru> Message-ID: <20230630194037.34b71bc8@limapholos> On Fri, 30 Jun 2023 16:25:47 +0200 (CEST) Michael Van Canneyt via lazarus wrote: >[...] > Honestly: I'll settle for actually managing to get a release out. +1000 Mattias From giuliano.colla at fastwebnet.it Fri Jun 30 21:16:04 2023 From: giuliano.colla at fastwebnet.it (Giuliano Colla) Date: Fri, 30 Jun 2023 21:16:04 +0200 Subject: [Lazarus] Lazarus trunk version number In-Reply-To: <20230630194037.34b71bc8@limapholos> References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de> <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de> <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru> <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru> <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru> <20230630194037.34b71bc8@limapholos> Message-ID: <84860fdd-28bc-612a-a592-50d9af6e5bba@fastwebnet.it> Il 30/06/23 19:40, Mattias Gaertner via lazarus ha scritto: > Michael Van Canneyt via lazarus wrote: > >> [...] >> Honestly: I'll settle for actually managing to get a release out. > +1000 +1000 me too. If the brilliant minds which have elaborated a new numbering scheme had spent their time in something more productive, such as making life a little bit easier to developers, I believe that the Lazarus community would have appreciated much more! For instance, there is the bad habit to "deprecate" without considering what happens to developers which must maintain their programs. I found it rather frustrating to replace all occurrences of clDark with clDkGray, just because clDark had been deprecated, instead of simply replacing the definition wit a line in types clDark = clDkGray. I've been taught that the golden rule to make code reusable is to hide the implementation and expose only the feature. Who cares how a color is implemented, provided that it shows the same? The same holds true for a lot of deprecations, which could be easily hidden without any adverse effect. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. -------------- next part -------------- An HTML attachment was scrubbed... URL: